关于 Meltdown 与 Spectre 对龙芯影响的初步看法

今天休息时候花了点时间思考龙芯平台有没有这两个漏洞。本来不想说话,但看到一个 RISC-V 阵营趁乱发的 PR 稿(https://riscv.org/2018/01/more ... -isa/ ),气死了,就来写点东西。原贴在贴吧发的,果然被秒删了,可能因为带了一些链接的缘故吧。那就来这边发了,正好小白也少。

关于 Meltdown,讲道理,龙芯实际上完全有可能受影响。因为 Linux 页表在 4.15-rc6 之前的的确确只有 1 份,而龙芯上并没有人做实验确认龙芯 MMU 面对攻击场景的行为模式。正常而言,即便单纯出于直觉判断,由于 TLB 的存在,mapped pages 肯定后续访问要快一些,这就很爆炸了;只是还需要在龙芯上找到类似 Intel TSX-NI 的降低操作系统 exception handler 运行时间噪声的机制。如果这种机制确实存在,那龙芯其实跟 Intel 一样爆炸。只是关心的人暂时没那么多罢了。(当然该关心的都在关心,这个没跑了。)

至于 Spectre,看了下 gist.github.com 有一份源码;用到了 rdtscp 跟 clflush 两个指令,试图从 victim_function 里间接读取它访问的内存。龙芯上 rdtsc(p) 是有等价物的,它貌似叫 rdhwr $31 还是 $29 来着,忘记了;clflush 从用户态刷缓存的,我找了一圈,貌似没看到,只有 Linux/MIPS wiki 上有讲到用系统调用让内核代劳,不清楚语义。有兴趣的小伙伴可以仔细研究一下 MIPS 指令集跟龙芯的用户手册。

总之就是希望大家可以讨论一下,最好能试着在龙芯上编译运行这两个漏洞的 PoC;能复现的话,就是对龙芯现阶段最好的事情之一了。

7 个评论

我记得这个 bug ,主要是预测运行错误后,回滚没有完全刷回数据,导致 TLB 里面的东西有些残留。这样通过特殊的命令,可以诱发地址越界,读取到其他位置的内存来获取数据。
最终还是看 CPU 执行的情况,是不是正确刷新了所有数据了。但是 CPU 内部如何执行,龙芯应该自己心里有数。
嗯。我个人感觉龙芯的 PR 应该过一阵子会出来。至少至少要比 zhaoxin 之流出得快,当然不受影响的话那就好上加好了。
应该只有这个分支预测的漏洞可能比较大。
龙芯可能有Spectre,但应该没有Meltdown。原因在于: 1,龙芯(或者说MIPS64)的内核页表和进程页表是分开的,如果你们非要说共享,肯定是你们没仔细看内核代码。2,MIPS的用户态地址/内核态地址是硬件层面就划分好了的,不是通过页表权限位区分的。3,龙芯可能存在指令退休不彻底问题,但由于前面两点,满足不了Meltdown的充分条件。
xen0n

xen0n 回复 lemote1

emmmm,确实上次看 arch/mips/mm 代码是去年了(移植 Loongnix 补丁到 4.7 的时候)。。。MIPS 用户态跟内核态地址空间确实是写死的,kseg0 kseg1 什么的我记得。龙芯用户手册里那一块看得我最头疼,也没记住多少。是时候重新翻出来看一眼了!!!
PoC 测试完成,没能复现。。。。
http://ask.loongnix.org/?/article/109
我也在尝试复现Spectre的Proof-of-Concept,不过也还是没成功 :(
__rdtscp()这个命令我找到的一个方法是通过"mfc0 %0, $25"这样个读取协处理器0的25号计数器的方法来知道当前的时钟周期数的(真的是可以在用户态读取的,貌似在这一点和其它的MIPS处理器不太一样)。然而这个方法需要先插入一个内核模块把计数器的事件设定为时钟周期才行。网上有篇博文讲如何制作那个模块。
清除缓存的命令貌似也要通过协处理器0进行,所以用户态是触摸不到的。只能用系统调用代劳。

将这两个方法组合起来,着实是能看见有缓存和没缓存的数据访存时间差异;大概是30个时钟周期 vs 80个时钟周期。差距之大,应当是容易能分辨出来的。

我猜不知是不是因为2F貌似没有那种一模一样的猜测执行的机制,所以导致不会在x >= array1_size的情况下猜测执行victim_function,也就不会将恶意指针指向的地址的内容装入cache中了。

要回复文章请先登录注册