CVE-2018-3639 | 最新侧信道攻击详细分析
本CSZQ最近对CPU相关漏洞感兴趣，于是深入研究了下CVE-2018-3639也就是Spectre4（幽灵4），有不对的地方欢迎指正。
简介
根据微软的一篇博客，已经发现的可用于揣测执行侧信道攻击的分支原语（英文原词在这里，speculation primitives，不太好翻译，就直译了）共有4种，分别是条件分支预测失误（conditional branch misprediction）、间接分支预测失误（indirect branch misprediction）、异常传递或延期（exception delivery or deferral）以及今天的主角揣测存储绕过（Speculative Store Bypass）。
详细分析
直接上代码的最重要部分，此代码经过个人添加了注释并修改过一些BUG，可以在文章最后下载源码对照查看每个变量的含义：
最重要的代码在115行和122行，在C语言层面看不出任何问题，请查看汇编代码：
汇编代码中红色部分为115行代码，绿色部分为122行代码，紫色部分即为出现问题的关键代码。
这两行代码出现问题的原因是执行当前代码的核心认为两条指令仅存在输出相关，因此可以使用寄存器重命名的方式并行执行，在《计算机体系结构：量化研究方法（第五版）》中可以找到相关解释：
并行执行一定会出问题吗，那不一定，还需要让执行单元先执行testfun+138指令再执行test+135指令，这样才能保证testfun+138会错误的影响cache。示例代码能够达成这个条件的原因是test+135指令与testfun+128指令相关，因此需要等待前面代码执行完毕，而test+138则没有这个顾虑。
继续深入到核心内部的执行单元，查看其到底是如何完成并行执行的，下图是intel的sandy bridge微架构执行单元：
查询AMD的17代处理器微架构文档，查询到如下信息：
所以可以判断上述两条宏观指令分别被翻译为单条存储相关微指令和单条加载相关微指令，结合上述寄存器重命名技术，因此可以判断在此微架构中使用port2和port4来并行执行两条指令，真相大白。
虽然在test+135存储指令执行完毕后，test+138指令由于错误会回退，但是已经受到影响的cache不会回退，所以可以结合 rdtscp 指令对 cache line 进行时间测试观察是否cache hit即可判断出到数据是多少。
还记得幽灵1么，它主要是由于错误的分支预测导致的 cache line 缓存了错误的数据，而幽灵4，主要是由于错误的揣测执行（暗自揣测圣意认为两条指令无关）造成的。
不负责任的猜想
Meltdown，忘记从哪里看到的一个说法，虽然AMD也有异常抑制技术，但是不受到该漏洞影响的原因是核心的执行单元有限，个人觉得应该是AMD的Store和load执行单元为同一个所以免疫，有待后续查证，附带上几个Intel和AMD的架构以供参考：
Intel Haswell微架构：
Intel sandy bridge微架构：
AMD 17th 架构
DEMO程序编译命令：
gcc -o Spec4 Speculative4.c -Wall -DHIT_THRESHOLD=50 -DNO_INTERRUPTS -ggdb
参考文献
漏洞PoC地址：
https://www.exploit-db.com/exploits/44695/
微软针对CVE-2018-3639的解释：
https://blogs.technet.microsoft.com/srd/2018/05/21/analysis-and-mitigation-of-speculative-store-bypass-cve-2018-3639/
intel sandy bridge微架构详解：
https://en.wikichip.org/wiki/intel/microarchitectures/sandy_bridge_(client)#MSROM_.26_Stack_Engine
intel sandy bridge微架构详解（中文）：
http://www.mouseos.com/arch/intel_microarchitecture.html
AMD 17代处理器优化说明：
https://developer.amd.com/wordpress/media/2013/12/55723_3_00.ZIP
架构相关的一本书：
《计算机体系结构：量化研究方法（第五版）》
Intel官方手册：
64-ia-32-architectures-optimization-manual.pdf
其他额外资料
AMD开发手册：
https://developer.amd.com/resources/developer-guides-manuals/
已知的CPU漏洞汇总：
https://wiki.osdev.org/CPU_Bugs
本CSZQ最近对CPU相关漏洞感兴趣，于是深入研究了下CVE-2018-3639也就是Spectre4（幽灵4），有不对的地方欢迎指正。
简介
根据微软的一篇博客，已经发现的可用于揣测执行侧信道攻击的分支原语（英文原词在这里，speculation primitives，不太好翻译，就直译了）共有4种，分别是条件分支预测失误（conditional branch misprediction）、间接分支预测失误（indirect branch misprediction）、异常传递或延期（exception delivery or deferral）以及今天的主角揣测存储绕过（Speculative Store Bypass）。
详细分析
直接上代码的最重要部分，此代码经过个人添加了注释并修改过一些BUG，可以在文章最后下载源码对照查看每个变量的含义：
最重要的代码在115行和122行，在C语言层面看不出任何问题，请查看汇编代码：
本文来自无奈人生安全网
汇编代码中红色部分为115行代码，绿色部分为122行代码，紫色部分即为出现问题的关键代码。
这两行代码出现问题的原因是执行当前代码的核心认为两条指令仅存在输出相关，因此可以使用寄存器重命名的方式并行执行，在《计算机体系结构：量化研究方法（第五版）》中可以找到相关解释：
并行执行一定会出问题吗，那不一定，还需要让执行单元先执行testfun+138指令再执行test+135指令，这样才能保证testfun+138会错误的影响cache。示例代码能够达成这个条件的原因是test+135指令与testfun+128指令相关，因此需要等待前面代码执行完毕，而test+138则没有这个顾虑。
继续深入到核心内部的执行单元，查看其到底是如何完成并行执行的，下图是intel的sandy bridge微架构执行单元：
查询AMD的17代处理器微架构文档，查询到如下信息： 内容来自无奈安全网
所以可以判断上述两条宏观指令分别被翻译为单条存储相关微指令和单条加载相关微指令，结合上述寄存器重命名技术，因此可以判断在此微架构中使用port2和port4来并行执行两条指令，真相大白。
虽然在test+135存储指令执行完毕后，test+138指令由于错误会回退，但是已经受到影响的cache不会回退，所以可以结合 rdtscp 指令对 cache line 进行时间测试观察是否cache hit即可判断出到数据是多少。
还记得幽灵1么，它主要是由于错误的分支预测导致的 cache line 缓存了错误的数据，而幽灵4，主要是由于错误的揣测执行（暗自揣测圣意认为两条指令无关）造成的。
不负责任的猜想
Meltdown，忘记从哪里看到的一个说法，虽然AMD也有异常抑制技术，但是不受到该漏洞影响的原因是核心的执行单元有限，个人觉得应该是AMD的Store和load执行单元为同一个所以免疫，有待后续查证，附带上几个Intel和AMD的架构以供参考：
Intel Haswell微架构：
Intel sandy bridge微架构：
AMD 17th 架构
DEMO程序编译命令：
gcc -o Spec4 Speculative4.c -Wall -DHIT_THRESHOLD=50 -DNO_INTERRUPTS -ggdb
参考文献
漏洞PoC地址：
https://www.exploit-db.com/exploits/44695/
微软针对CVE-2018-3639的解释：
https://blogs.technet.microsoft.com/srd/2018/05/21/analysis-and-mitigation-of-speculative-store-bypass-cve-2018-3639/
intel sandy bridge微架构详解：
https://en.wikichip.org/wiki/intel/microarchitectures/sandy_bridge_(client)#MSROM_.26_Stack_Engine copyright 无奈人生
intel sandy bridge微架构详解（中文）：
http://www.mouseos.com/arch/intel_microarchitecture.html
AMD 17代处理器优化说明：
https://developer.amd.com/wordpress/media/2013/12/55723_3_00.ZIP
架构相关的一本书：
《计算机体系结构：量化研究方法（第五版）》
Intel官方手册：
64-ia-32-architectures-optimization-manual.pdf
其他额外资料
AMD开发手册：
https://developer.amd.com/resources/developer-guides-manuals/
已知的CPU漏洞汇总：
https://wiki.osdev.org/CPU_Bugs