Spectre 攻击的那个 PoC 有人复现了吗

[yksoft1]

漏洞论文： https://spectreattack.com/spectre.pdf 。 我试了一下最后附录贴出的 Windows 下 C 语言 PoC，用 mingw-w64 32 位版编译出来了。 因为用了 clflush 和 rdtscp 两个指令，理论上应该只有支持 SSE2 还是 SSE3 的 CPU 可以运行这个。跑了自己的一些机器， Core i7-2720QM Win8.1:

Core i5-2520M WinXP SP3 WEPOS:

在支持 SSE3 但没有分支预测的 Atom N270、N2600 上都崩溃，错误 0xc000001d

Atom Z3735F 执行成功了。。

在 Dothan 核心的赛扬 900 （ eeepc 701 ）上崩溃

另外，Meltdown 的 Windows x64 下的 poc 找到了，但是好几个人都复现不成功。

我发现一个问题，这个在老机器甚至 Penryn Core2 上都跑不起来，0xc000001d 是“非法指令”错误。究其原因，是因为 exploit 使用了 rdtscp 这个所谓的“序列化的 rdtsc ”指令，这个哪怕在 Penryn 上都没有，需要 i7 一代以上。
另外，追加一个情报，A8-3530MX 受影响。

我把原代码中的 time1 = __rdtscp( & junk); /* READ TIMER / 和 time2 = __rdtscp( & junk) - time1; / READ TIMER & COMPUTE ELAPSED TIME */

改成了 _mm_mfence(); time1 = __rdtsc(); /* READ TIMER / 和 _mm_mfence(); time2 = __rdtsc() - time1; / READ TIMER & COMPUTE ELAPSED TIME */

之后，就可以在Atom N270和Dothan赛扬正常运行了。Dothan赛扬返回结果基本正常，有时候有几个不能显示；N270一个都不能正确显示。 (!dothan)[http://wx2.sinaimg.cn/large/5ca04df0gy1fn539e315dj20m80dc0to.jpg] (!n270)[http://wx2.sinaimg.cn/large/5ca04df0gy1fn539ec41yj20sg0go7cq.jpg]

[zts1993]

好像两个最基本都是需要乱序执行。老 U 和老 ATOM 都不行的

[am241]

正在试…也许和 cache 大小 and 分支预测器的深度有关

[yksoft1]

@zts1993 Dothan 有 SSE2，有乱序执行。

[yksoft1]

Core i5 U 560，WinXP SP3，运行成功。


AMD A4-1200，运行没有报错，但是结果只有部分正确。

[est]

https://access.redhat.com/security/vulnerabilities/speculativeexecution

IBM 的 power 系列也受影响

[wwqgtxx]

试了一下 i7 4790, i7 3632qm, i5 520m, z3735f 上都能复现

[lrxiao]

在找 Meltdown 的 PoC..看到一个 win 的 可能已经更新到修复版本了？

[yksoft1]

@lrxiao 不是系统问题，2003 x64 下都不能正确 guess

[redsonic]

linux 上面测试过了，结果贴在隔壁帖里了。老 cpu 可以用 rdtsc 代替 rdtscp，但几乎猜不中了。既然计时是侧信道泄漏的关键那 intel 只要弄个开关把计时模糊一下应该可以防止这类攻击。
另外 windows 的我编译了，运行时卡在 reading at malicious_x=FFFFF0E0 ......

[Quaintjade]

非洲农业不发达，必须要有金克拉！！！！

[yksoft1]

@redsonic 已经解决 rdtscp 的问题，用 mfence+rdtsc 可以替代。

[yksoft1]

@redsonic 我在 Windows 下使用 32 位 mingw-w64 编译的，参数很简单，
gcc -msse2 -std=c99 spectre.c -ospectre

[redsonic]

@yksoft1 我是在 vs2013 里面编译的，64、32 位都卡在那，我在调调 readMemoryByte()。
还有你那个 rdtscp 定义成这样吗？ 我试了一下老 core2 还是几乎猜不到。
unsigned long rdtscp()
{
unsigned int lo,hi;

__asm__ __volatile__
(
"mfence;rdtsc":"=a"(lo),"=d"(hi)
);
return (unsigned long)hi<<32|lo;
}

[yksoft1]

@redsonic VC 的 intristic 还不如 mingw 的。
我根本没用内联汇编，全部用的 intristic 调用的 mfence 和 rdtsc。
不能加入任何非内联的新函数，因为都会涉及到上下文的切换，使得无法正确获得结果。

[yksoft1]

Stackoverflow 上说，Linux 内核里实现不受乱序影响的高精度计时，AMD 平台是 mfence+rdtsc，Intel 平台则是 lfence+rdtsc.

[redsonic]

@yksoft1 我用 mingw-w64 编译又跑了一遍，老 core duo2 e6300 e6400 e6600 l7500 都猜不到，如果这个 PoC 没问题说明没有 invariant TSC 的 cpu 似乎很难通过侧信道攻击。

[yksoft1]

@redsonic 说了你 rdtsc 还有问题。你试试看 lfence+rdtsc ？不要用单独函数。直接写在 readMemoryByte 里面即可
问题是为啥 dothan 的赛扬能通过？

[yksoft1]

@redsonic 另外，试试看老移动平台。这个还有可能和 Speedstep 有点关系

[redsonic]

@yksoft1 我只启用一个核心，设置成实时优先级，mfence 和 lfence 都不起作用。dothan 我没有 没办法测试，不过手里的 core i 1 代 、2 代、4 代、5 代都中招。另外发现 core duo2 跑这个 PoC 要比中招的那几个慢非常多，trace 了一下几乎每个引用都慢很多，从这个角度看 core i 的访存设计可能真的和老 core duo2 差异蛮大的。dothan 应该就是 core duo1，不知道是不是这两代也有访存设计上的巨大差异。

[xqdoo00o]

https://github.com/gkaindl/meltdown-poc 有试过这个 poc 吗，我现在没编译环境测试不了。
@yksoft1

[redsonic]

@yksoft1 update： 刚才有疏忽，单核芯模式 core duo2 中招。dothan 应该都是单核心吧，所以中招。这样看老的 tsc 不准反而打掩护了。

[yksoft1]

@xqdoo00o
#include <sys/mman.h>

我现在没有任何 Linux 或 OSX 的环境。。。


@redsonic 你编译的时候优化开关是啥？我的 A4-1200，不开优化只有一部分能读出，-O2 全部读出

[redsonic]

@yksoft1 开不开优化结果都一样

[yksoft1]

@redsonic 我现在实现了一个支持三种计时方式（ rdtscp、mfence+rdtsc、lfence+rdtsc ）的版本。用-O2 参数编译，稍微跑了一下。
i5 U 560、i7 2720QM、i5 2520M：三种方式全都正确跑出
Dothan 核心 赛扬 353： 第一种崩溃，后两种正确跑出但有时会有不正确的结果
AMD A4-1200：第一种全部正确跑出而且程序跑得很快，后两种完全跑不出正确结果
Atom N270: 第一种崩溃，后两种完全跑不出正确结果。

其他人跑的：
赛扬 D 356：第一种崩溃，后两种完全跑不出正确结果。
还在等 Athlon 64 X2 5000+、 某个 Penryn 核心的至强的结果
现在我估计 Prescott 的 U 应该不行，Dothan 却可以。

[redsonic]

搜到霓虹那边关于 tsc 的一张表应该能判别哪些 cpu 会受到影响
http://www.02.246.ne.jp/~torutk/cxx/clock/cpucounter.html

[yksoft1]

AMD Athlon 64 X2 5000+（ K8 架构）：三种方式全都正确跑出
奔腾双核 E6500K （ Penryn 架构，Wolfdale 核心）：多核模式下，第一种崩溃，后两种完全跑不出正确结果。

现在给人的感觉是，这个东西需要非常精确的 TSC 时序才能够成功。