從硬體上修復Meltdown與Spectre會是怎樣的思路？困難在哪裡？

01-13

meltdown這個低許可權的speculative的讀操作，檢查到對應的地址是內核高許可權的頁，這時不把數據讀到cpu就可以了。沒中招的處理應該就是這麼做的。

spectre這個估計不好避開，先訓練分支預測，然後去讀邊界外的數據。分支預測先連續多次朝一個方向，之後突然錯一次，大部分分支預測器都會把後面這次預測為之前的方向。可能全局歷史比較長的預測器會好些，需要更多的訓練次數，這樣會降低讀取數據的速度。不過spectre這個實施起來沒那麼好操作，要讀取內核數據也比meltdown難。

補充下最新信息：

meltdown因為已有的cpu硬體上沒法修復，只能通過軟體，因此現在Linux打開了pti來解決這個問題。未來的趨勢應該也是把內核和用戶的頁表獨立開來。硬體這邊就是看下怎麼減少切換開銷，arm的ttbr0和ttbr1估計是個好辦法。

spectre現在也有補丁出來了，通過控制分支預測器來解決。內核最新的mail list里有討論了。

已經有答案提到如何修復了。看見有人問為什麼現在的部分CPU設計里預測錯誤路徑上取上來的cache 塊沒有被無效化，我嘗試解釋一下。

首先，我覺得無效掉分支預測錯誤取上來的塊不難，但是在meltdown出現之前，這樣做的收益很小。考慮三方面的問題：正確性、性能和功耗。

不無效化不會影響正確性，這是顯然的；
如果要增加這部分邏輯，設計時肯定要增加相應的電路，運行時也會增加相應的動態功耗。這個功耗不會很高，但也不會很小。如果每次分支預測錯誤沖刷50條指令，那麼這期間大概需要無效10個cache 塊。如果說只在用戶態程序投機載入了內核頁的時候沖刷，那麼沖刷的cache 塊會少很多，但是還需要增加額外的判斷邏輯。
性能。因為這不在關鍵路徑上，應該不會導致頻率降低，所以不考慮頻率了。考慮這個塊的存在對cache性能影響，假設使用LRU替換演算法。我們將分支預測錯誤時取上來的塊稱為MB，將其映射到的set裡面的最近最少用的塊稱為LRU-B。當MB取到這一層cache之後，LRU-B已經被踢了。然後我們需要討論的問題就是此時無效掉MB對cache性能的影響。

假設不無效掉MB。因為我的觀點是不無效MB對性能影響很小，不妨假設MB永遠不會hit。那麼在MB被替換出去之前，該set的容量便從N路下降到了N-1路，重用距離等於N的塊將會因為MB的存在而無法命中。對2路或者4路的cache來講，會有一定的損失。但是現在主流的X86處理器從第一級cache開始，data cache的相聯度就是8，重用距離等於8的概率就明顯小很多了，因此損失不大。
假設無效掉MB，因為LRU-B已經被覆蓋掉了，一般的cache設計無法再將LRU-B填回來了，那麼該set就會多出一個無效塊，下次充填的時候就會用這個塊。

綜合來看，無效MB會有額外的功耗，增加一定的設計複雜度；不無效MB損失很小。如果採用非LRU的替換演算法，損失有可能會更小。

當然，我不知道Intel的架構師怎麼考慮的，以上純屬自己的推測，歡迎交流指正。

硬體上修復 Spectre 其實並不困難，而且不會帶來多少負面影響

亂序執行序列里的 LOAD 類操作可以分兩種情況，cache 里能夠命中或是不能命中

如果數據能夠命中，那麼像以前一樣，直接執行 LOAD 就可以了，這個操作是否會因為分支預測錯誤而被拋棄都不受影響

如果沒有命中，那就必須等到亂序序列中前方的分支結果出來之後，才決定是否訪問內存，這樣就避免了無效的操作引起的cache副作用

考慮到數據的局域性，大部分LOAD的數據其實都已在 cache 中，所以最終性能只會受到很輕微的影響

個人感覺meltdown比較好解決，另兩個則不太好操作，簡單粗暴的辦法是不再做這些優化，那還不如不解決。

不是搞硬體的，門外漢表達幾個疑問：

Spectre既然是利用了cache的副作用，那麼分支預測錯誤的時候清理掉cache可不可行呢？比如直接把本輪投機時載入的cache line失效掉……

這樣會對性能造成很大影響嗎？這個難度是在於清理cache還是在於跟蹤cache的預取？還是說現有的性能中有一部分就是靠這種不安全的預取獲得的？

瀉藥，我就是個做遊戲的

…………我猶記得我是個護膚博主，然後被逼著參與解答情感問題，現在連cpu問題都邀請我？？？？怕是想搞死我。