怎樣進行CVE-2018-3639最新邊信道攻擊的詳細分析

今天就跟大家聊聊有關怎樣進行CVE-2018-3639最新邊信道攻擊的詳細分析，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

前言

出于對CPU相關漏洞的興趣，我深入研究了下CVE-2018-3639（Spectre4，幽靈4），有不正確的地方歡迎指正。

根據微軟的一篇博客，已經發(fā)現(xiàn)的可用于揣測執(zhí)行邊信道攻擊的分支（Speculation primitives）共有4種，分別是條件分支預測失誤（conditional branchmisprediction）、間接分支預測失誤（indirect branch misprediction） 、異常傳遞或延期（exception deliveryor deferral）以及今天的主角揣測存儲繞過（Speculative StoreBypass）。

詳細分析

直接上代碼的最重要部分，此代碼經過個人添加了注釋并修改過一些BUG，可以在文章最后下載源碼對照查看每個變量的含義： 

最重要的代碼在115行和122行，在C語言層面看不出任何問題，請查看匯編代碼：

匯編代碼中紅色部分為115行代碼，綠色部分為122行代碼，紫色部分即為出現(xiàn)問題的關鍵代碼。

這兩行代碼出現(xiàn)問題的原因是執(zhí)行當前代碼的核心認為兩條指令僅存在輸出相關，因此可以使用寄存器重命名的方式并行執(zhí)行，在《計算機體系結構：量化研究方法（第五版）》中可以找到相關解釋：

并行執(zhí)行不一定會出問題，還需要讓執(zhí)行單元先執(zhí)行testfun+138指令再執(zhí)行test+135指令，這樣才能保證testfun+138會錯誤的影響cache。示例代碼能夠達成這個條件的原因是test+135指令與testfun+128指令相關，因此需要等待前面代碼執(zhí)行完畢，而test+138則沒有這個顧慮。

繼續(xù)深入到核心內部的執(zhí)行單元，查看其到底是如何完成并行執(zhí)行的，下圖是Intel的Sandy Bridge微架構執(zhí)行單元：

查詢AMD的17代處理器微架構文檔，查詢到如下信息：

所以可以判斷上述兩條宏觀指令分別被翻譯為單條存儲相關微指令和單條加載相關微指令，結合上述寄存器重命名技術，因此可以判斷在此微架構中使用port2和port4來并行執(zhí)行兩條指令，真相大白。

雖然在test+135存儲指令執(zhí)行完畢后，test+138指令由于錯誤會回退，但是已經受到影響的cache不會回退，所以可以結合rdtscp指令對cache lin 進行時間測試觀察是否cache hit即可判斷出到數(shù)據是多少。

不知讀者還記得幽靈1不，它主要是由于錯誤的分支預測導致的 cache line 緩存了錯誤的數(shù)據。而幽靈4，主要是由于錯誤的揣測執(zhí)行（暗自揣測圣意認為兩條指令無關）造成的Meltdown，來源想不起來了。雖然AMD也有異常抑制技術，但是不受到該漏洞影響的原因是核心的執(zhí)行單元有限，個人覺得應該是AMD的Store和load執(zhí)行單元為同一個所以免疫，有待后續(xù)查證，附帶上幾個Intel和AMD的架構以供參考：

Intel Haswell微架構：

Intel Sandy Bridge微架構：

AMD 17th 架構：

DEMO程序編譯命令：        
   

gcc -o Spec4 Speculative4.c -Wall-DHIT_THRESHOLD=50 -DNO_INTERRUPTS -ggdb

看完上述內容，你們對怎樣進行CVE-2018-3639最新邊信道攻擊的詳細分析有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業(yè)資訊頻道，感謝大家的支持。