一步一步理解CPU芯片问题：Meltdown与Spectre

0X00 历史之日
ASP站长网2018年1月3日，Google Project Zero（GPZ）团队安全研究员Jann Horn在其团队博客[1]中爆出CPU芯片的两组漏洞，分别是Meltdown与Spectre。
 
Meltdown对应CVE-2017-5754（乱序执行缓存污染），Spectre对应CVE-2017-5753（边界检查绕过）与CVE-2017-5715（分支目标注入）。看CVE编号就能知道，这两组漏洞早在2017年6月就已经由GPZ团队向英特尔提交，而在差不多时间由Lipp等人发布的论文Meltdown[2]与Spectre Attacks[3]也详细描述了这一攻击，从文中的声明来看，Lipp等人与GPZ团队似乎是独立发现了这两组漏洞。
 
Meltdown漏洞影响几乎所有的Intel CPU和部分ARM CPU，而Spectre则影响所有的Intel CPU和AMD CPU，以及主流的ARM CPU。从个人电脑、服务器、云计算机服务器到移动端的智能手机，都受到这两组硬件漏洞的影响。这必将是要在安全界乃至整个计算机界载入史册的重要日子，各种报道与公告乃至技术细节充斥着整个朋友圈、微博与媒体，可以说是路人皆知了。为何这两个漏洞如此特别，引起大家如此重视呢？ 请往下看。
 
0X01 漏洞原理
这两组漏洞来源于芯片厂商为了提高CPU性能而引入的两种特性：乱序执行（Out-of-Order Execution）和预测执行(Speculative Execution)。
 
乱序执行与预测执行
早期的处理器依次顺序执行既定的处理器指令，而现代处理器为了提高性能并不严格按照指令的顺序串行执行，而是对执行进行相关性分析后并行处理乱序执行。比如当处理器中的某些指令需要等待某些资源，处理器不会真的在这里等待而停止指令的执行，而是利用等待资源的时间继续执行后续的指令。在支持乱序执行的CPU中，后面的指令可能在前面指令执行结束前就开始执行了。
 
为了保证程序运行的正确性，处理器会对指令执行安全检查，只有当前用户权限符合指令权限时才能被执行，比如用户空间的指令访问内核内存处理器就会抛出异常。然而安全检查这个操作只有在指令退休（retirement-一条指令退休只有当它的执行的结果真正被提交并对系统可见时才会发生）时才会进行。也就是说，如果在乱序执行中，指令并没有真正执行完成而只是加载到缓存中（下文会提）是不会执行安全检查的。而此时由于乱序执行而被提前执行的指令会被处理器丢弃，但由于乱序执行的指令对缓存的操作在这些指令被丢弃时不会被重置。正是安全检查与乱序执行的空窗期才会让Meltdown有机可乘。
 
预测执行涉及到程序的控制流，现在处理器不是去解析所有分支指令后然后决定执行哪个操作，而是预测哪个控制流会更有可能被运行再提取相应的指令代码执行。如果预测正确的话，会带来很高的性能提升并提高处理器的并行性。如果预测错误，那些被预测执行的不正确结果会被丢弃，处理器会将状态恢复到预测执行行前的正确状态，再重新跳转到正确执行的分支或指令中运行。与乱序执行类似，预测执行对处理器缓存的操作会被保留。
 
这种机制从宏观上看似乎没什么问题，但由于处理器的缓存（cache）机制，那些被预测执行或乱序执行的指令会被先加载到缓存中，但在处理器恢复状态时并不会恢复处理器缓存的内容。而最新的研究表明攻击者可以利用缓存进行侧信道攻击，而Meltdown与Spectre从本质上来看属于利用处理器的乱序执行或预测执行漏洞进行的缓存侧信道攻击。
 
缓存侧信道攻击
基于缓存的侧信道攻击目前在学术界研究中非常流行，比如俄亥俄州立大学的Yinqian Zhang教授[10]在此领域做了许多非常杰出的工作。缓存通过数据共享来加快数据访问，也就是说缓存命中与失效对应的响应时间是有差别的，攻击者正是利用这种时间的差异性来推测缓存中的信息，从而获得隐私数据。
 
缓存侧信道攻击主要有Evict+Time[7]、Prime+Probe[6])与Flush+Reload[5]等攻击方式，这里主要简单介绍一下Flush+Reload，也是下文exploit中利用的方法。假设攻击者和目标程序共享物理内存（也可以是云中不同虚拟机共享内存），攻击者可以反复利用处理器指令将监控的内存块（某些地址）从缓存中驱逐出去，然后在等待目标程序访问共享内存（Flush阶段）。然后攻击者重新加载监控的内存块并测量读取时间(Reload阶段)，如果该内存块被目标程序访问过，其对应的内存会被导入到处理器缓存中，则攻击者对该内存的访问时间将会较短。通过测量加载时间的长短，攻击者可以清楚地知道该内存块是否被目标程序读取过。
 
Meltdown与Spectre利用这种侧信道可以进行越权内存访问，甚至读取整个内核的内存数据。
 
Meltdown攻击指令序列
以一个简化的Meltdown攻击指令序列为例：
 
; rcx = kernel address
; rbx = probe_array
mov al, byte [rcx]
shl rax, 0xc
mov rbx, qword [rbx + rax]
 
rcx寄存器存放用户空间程序不可访问的内核地址
 
rbx寄存器指向探测数组probe_array
 
一个具有用户级权限的攻击者在第三条指令中试图访问内核地址，处理器会对其作安全检查，检查该进程是否有权限访问该地址，于是这条指令会触发异常，该指令及之后的指令对寄存器的修改都会被丢弃，处理器重新回到能正常执行的指令中。但由于处理器采用乱序执行方式，在等待处理器完成该指令执行的同时（权限检查结束之前），后面两条指令已经被执行了（尽管最终会被丢弃）。
 
将指令3读取到的数据乘以4096（4KB），至于为什么是4096，会在下文具体exploit中介绍。
 
将指令4的结果作为索引对探测数组probe_array(rbx[al*4096])进行访问并进行探测。由于一个内存页的大小是4KB，不同的数据将会导致不同的内存页被访问并存放到CPU缓存中。
 
此后，攻击者就可以通过缓存侧信道攻击，不断遍历加载rbx[al*4096]，由于该数据此时已经在缓存中，攻击者总会遍历出一个加载时间远小于其它的数据，推测哪个内存页被访问过了，从而推断出被访问的内核内存数据。
 
强调一下，攻击者的目标是要不断探测probe_array来获取内核地址指向的数据。
 
0X02 Exploit 分析
来看在github上爆出的一个POC[4]，也是目前来看比较能让大家深入理解meltdown的一个exploit。该POC能利用应用程序读取内核中的linux_proc_banner变量，这个变量存储了Linux内核的版本信息，可以通过命令cat /proc/version获取。cat /proc/version触发了系统调用将linux_proc_banner变量的信息返回给应用程序。而利用meltdown漏洞可以直接从应用程序中访问linux_proc_banner变量，破坏了内存隔离。
该POC首先利用“sudo cat /proc/kallsyms | grep “linux_proc_banner””获取linux_proc_banner在内核中的地址，再读取该地址上的值。从该地址读取变量的值正是利用了meltdown漏洞。
 
 
 
总的来说，攻击者要窃取内核数据，包括四个过程：Flush阶段，Speculate阶段，Reload阶段以及Probe阶段。值得注意的是，Reload阶段包含在Speculate阶段中，但由于Reload阶段与Flush阶段是一个完整的缓存侧信道攻击过程，不得不把它单独列出来。整个执行顺序是Flush阶段-Speculate阶段（包含Reload阶段）-Probe阶段，这四个过程我们会在下文一一提到。为便于理解，先讲Speculate阶段。