怎样进行CVE-2018-3639最新边信道攻击的详细分析

今天就跟大家聊聊有关怎样进行CVE-2018-3639最新边信道攻击的详细分析，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。出于对CPU相关漏洞的兴趣，我深入研究了下CVE-2018-3639（Spectre4，幽灵4），有不正确的地方欢迎指正。根据微软的一篇博客，已经发现的可用于揣测执行边信道攻击的分支（Speculation primitives）共有4种，分别是条件分支预测失误（conditional branchmisprediction）、间接分支预测失误（indirect branch misprediction） 、异常传递或延期（exception deliveryor deferral）以及今天的主角揣测存储绕过（Speculative StoreBypass）。
直接上代码的最重要部分，此代码经过个人添加了注释并修改过一些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 lin 进行时间测试观察是否cache hit即可判断出到数据是多少。不知读者还记得幽灵1不，它主要是由于错误的分支预测导致的 cache line 缓存了错误的数据。而幽灵4，主要是由于错误的揣测执行（暗自揣测圣意认为两条指令无关）造成的Meltdown，来源想不起来了。虽然AMD也有异常抑制技术，但是不受到该漏洞影响的原因是核心的执行单元有限，个人觉得应该是AMD的Store和load执行单元为同一个所以免疫，有待后续查证，附带上几个Intel和AMD的架构以供参考：Intel Haswell微架构：Intel Sandy Bridge微架构：AMD17th 架构：DEMO程序编译命令：
gcc -o Spec4 Speculative4.c -Wall-DHIT_THRESHOLD=50 -DNO_INTERRUPTS -ggdb看完上述内容，你们对怎样进行CVE-2018-3639最新边信道攻击的详细分析有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注云编程开发博客行业资讯频道，感谢大家的支持。

相关推荐: 基于天然概率的无需人为平衡的skiplist的美之展现

任何事情都无法阻挡我对一种简单之美的由衷惊叹。半夜思索，无法入眠，索性起床看会书，关于中东文明的，可是又看不进去，也许是潮热的原因 吧…还不如静下心来写一篇意识流文章，我指的是不用思考的那种，我已经被近东，中东的错综复杂的历史搞的有点烦了，那真是太难了。然…