这是一个创建于 2539 天前的主题，其中的信息可能已经有所发展或是发生改变。
漏洞论文： 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 找到了，但是好几个人都复现不成功。
第 1 条附言 · 2018-01-04 22:26:06 +08:00
我发现一个问题，这个在老机器甚至 Penryn Core2 上都跑不起来，0xc000001d 是“非法指令”错误。究其原因，是因为 exploit 使用了 rdtscp 这个所谓的“序列化的 rdtsc ”指令，这个哪怕在 Penryn 上都没有，需要 i7 一代以上。
另外，追加一个情报，A8-3530MX 受影响。
另外，追加一个情报，A8-3530MX 受影响。
第 2 条附言 · 2018-01-05 01:32:31 +08:00
我把原代码中的 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]
 |
1
zts1993 2018-01-04 20:22:04 +08:00
好像两个最基本都是需要乱序执行。老 U 和老 ATOM 都不行的
|
 |
2
am241 2018-01-04 20:25:19 +08:00 via Android
正在试…也许和 cache 大小 and 分支预测器的深度有关
|
 |
4
yksoft1 OP Core i5 U 560，WinXP SP3，运行成功。
 AMD A4-1200，运行没有报错，但是结果只有部分正确。  |
 |
5
est 2018-01-04 23:24:43 +08:00
|
 |
6
wwqgtxx 2018-01-04 23:49:29 +08:00
试了一下 i7 4790, i7 3632qm, i5 520m, z3735f 上都能复现
|
 |
7
lrxiao 2018-01-04 23:50:30 +08:00
在找 Meltdown 的 PoC..看到一个 win 的 可能已经更新到修复版本了？
|
 |
9
redsonic 2018-01-05 00:33:11 +08:00
linux 上面测试过了，结果贴在隔壁帖里了。老 cpu 可以用 rdtsc 代替 rdtscp，但几乎猜不中了。既然计时是侧信道泄漏的关键那 intel 只要弄个开关把计时模糊一下应该可以防止这类攻击。
另外 windows 的我编译了，运行时卡在 reading at malicious_x=FFFFF0E0 ...... |
 |
10
Quaintjade 2018-01-05 00:41:05 +08:00
非洲农业不发达，必须要有金克拉！！！！
|
|
12
yksoft1 OP @redsonic 我在 Windows 下使用 32 位 mingw-w64 编译的，参数很简单，
gcc -msse2 -std=c99 spectre.c -ospectre |
|
13
redsonic 2018-01-05 01:43:52 +08:00
@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; } |
|
14
yksoft1 OP @redsonic VC 的 intristic 还不如 mingw 的。
我根本没用内联汇编，全部用的 intristic 调用的 mfence 和 rdtsc。 不能加入任何非内联的新函数，因为都会涉及到上下文的切换，使得无法正确获得结果。 |
|
15
yksoft1 OP Stackoverflow 上说，Linux 内核里实现不受乱序影响的高精度计时，AMD 平台是 mfence+rdtsc，Intel 平台则是 lfence+rdtsc.
|
|
16
redsonic 2018-01-05 14:27:52 +08:00
@yksoft1 我用 mingw-w64 编译又跑了一遍，老 core duo2 e6300 e6400 e6600 l7500 都猜不到，如果这个 PoC 没问题说明没有 invariant TSC 的 cpu 似乎很难通过侧信道攻击。
|
|
17
yksoft1 OP @redsonic 说了你 rdtsc 还有问题。你试试看 lfence+rdtsc ？不要用单独函数。直接写在 readMemoryByte 里面即可
问题是为啥 dothan 的赛扬能通过？ |
|
19
redsonic 2018-01-05 20:51:42 +08:00
@yksoft1 我只启用一个核心，设置成实时优先级，mfence 和 lfence 都不起作用。dothan 我没有 没办法测试，不过手里的 core i 1 代 、2 代、4 代、5 代都中招。另外发现 core duo2 跑这个 PoC 要比中招的那几个慢非常多，trace 了一下几乎每个引用都慢很多，从这个角度看 core i 的访存设计可能真的和老 core duo2 差异蛮大的。dothan 应该就是 core duo1，不知道是不是这两代也有访存设计上的巨大差异。
|
 |
20
xqdoo00o 2018-01-05 21:08:06 +08:00
|
|
21
redsonic 2018-01-05 21:18:44 +08:00
@yksoft1 update： 刚才有疏忽，单核芯模式 core duo2 中招。dothan 应该都是单核心吧，所以中招。这样看老的 tsc 不准反而打掩护了。
|
|
22
yksoft1 OP |
|
24
yksoft1 OP @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 却可以。 |
|
25
redsonic 2018-01-05 22:32:42 +08:00
搜到霓虹那边关于 tsc 的一张表应该能判别哪些 cpu 会受到影响
http://www.02.246.ne.jp/~torutk/cxx/clock/cpucounter.html |
|
26
yksoft1 OP AMD Athlon 64 X2 5000+（ K8 架构）：三种方式全都正确跑出
奔腾双核 E6500K （ Penryn 架构，Wolfdale 核心）：多核模式下，第一种崩溃，后两种完全跑不出正确结果。 现在给人的感觉是，这个东西需要非常精确的 TSC 时序才能够成功。 |
Select Language
