谷歌、Facebook頻繁發現CPU核心不可靠，出現無法預測計算錯誤

機器之心報道

編輯：小舟、陳萍

最近谷歌和 Facebook 兩大公司頻繁檢測到 CPU 在一些情況下會以無法預測的方式出現計算錯誤。

CPU 一直都不是完全可靠的，自問世以來就一直存在出現錯誤的風險。這些風險不僅來源於設計上的一些疏忽，也源於環境條件和會產生故障的物理系統。但這些錯誤往往很少見，如果系統按預期運行，則只有極少部分計算會出現錯誤。大多數情況下，計算機晶片被視為值得信賴的。

然而，最近谷歌和 Facebook 兩大公司頻繁檢測到 CPU 出現一些「不當行為」，以至於他們正在敦促技術合作公司找到找出這些錯誤並補救的方法。

谷歌工程師 Peter Hochschild 在近日剛剛舉辦的 HotOS 2021 上說道：「生產團隊抱怨『機器破壞資料』的情況越來越多。」他表示：「這些機器被指控破壞了多個不同的、穩定的、偵錯良好的大型應用程式。機器都被各個獨立團隊反覆指責，並且這些指控是可信的。但傳統的診斷方法沒有發現它們有任何問題。」

開發者們更深入地查看了所涉及的程式碼和來自相關機器的操作遙測，谷歌工程師開始懷疑是硬體存在問題。他們調查發現硬體錯誤的發生率高於預期，這些問題在安裝後很長時間內偶爾會出現，並且出現在特定的單個 CPU 核心上，而不是整個晶片或一系列部件上。

谷歌的研究人員檢查了這些靜默損壞執行錯誤 (corrupt execution error，CEE) 後得出結論：這些錯誤應該歸咎於「易變的核心（mercurial core）」——CPU 在一些情況下偶爾會以一種無法預測的方式出現計算錯誤。

這些錯誤不是因為像 M1 晶片一樣的架構設計失誤，而且在製造測試期間也沒有檢測到這些問題。相反，谷歌工程師認為，之所以會出現錯誤，是因為我們已經將半導體制造推向了故障變得更加頻繁的地步，而我們缺乏提前識別故障的工具。

在一篇名為《Cores that don’t count》的論文中，Hochschild 及其同事列舉了計算機核心的不可靠性現在才受到關注的幾個原因，包括大型伺服器機群能夠讓罕見問題更加明顯、開發者們近來才更加關注整體可靠性和降低軟體錯誤率的相關改進。

論文地址：https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s01-hochschild.pdf

但該研究表示有一個更根本的原因：「越來越小的特徵尺寸越來越接近 CMOS 縮放的極限，並且架構設計的複雜性也在不斷增加。」並指出現有的驗證方法並不適用於發現偶爾出現的缺陷或部署後物理損壞的結果。

我們習慣於將計算機視為故障停止裝置，尤其是執行指令的核心，而大多數系統軟體都依賴於這種假設。隨著晶片製造朝著更小的特徵尺寸和更精細的計算結構發展，並且隨著引入新的複雜指令集以提高效能，我們發現了在製造測試期間沒有檢測到的計算錯誤。這些缺陷不能總是通過微程式碼更新等技術來緩解，並且這些缺陷可能與處理器內的特定元件有關，允許小型程式碼更改可能會影響可靠性。更糟糕的是，這些錯誤通常是悄無聲息的——唯一的變現就是出現計算錯誤。

這種「易變」的核心極為罕見，但在大量伺服器中，我們則可以觀察到它們造成的中斷，甚至足以將它們視為一個明顯的問題。這意味著需要硬體設計人員、處理器供應商和系統軟體架構師之間合作解決這種缺陷問題。

此外，谷歌的研究者提出了一些緩解該問題的方法，例如識別和去除「易變」核心。

「易變」核心的識別具有挑戰性，因為「易變」核心可能導致故障和資料損壞、而不當的識別可能會導致良好核心的浪費，並且識別過程的成本也很高。該研究對「易變」核心的識別過程進行了分類，包括：

自動化與人工；部署前與部署後；線下 vs. 線上； 基礎設施級別與應用級別。

不過，識別和去除「易變」核心並不總是能避免影響應用程式，並且識別可能不是完美的。因此谷歌的研究者提議設計能夠容忍 CEE 且沒有過多開銷的軟體？這將從以下幾點出發：

對特定於應用的機制施加一些負擔，應用「端到端 Argument」設計思想，這種思想指出正確性通常最好是在端點而非較低級別的基礎設施中進行檢查。

系統應該支援高效的檢查點，通過在不同的核心上重新啟動，以將失敗的計算重新恢復。

使用面向應用的成本高效檢測方法來決定是繼續通過檢查點還是重試。例如，在提交之前計算資料庫記錄的不變數以確認機器是否損壞了資料。

Facebook 也發現了同樣的問題

無獨有偶，Facebook 也注意到了這些錯誤。今年 2 月，Facebook 發表了一篇名為《 Silent Data Corruptions at Scale 》的論文，論文中寫到，與之前觀察到的資料中心相比，靜默資料損壞（SDC）正在成為一種更加普遍的現象。SDC 不能通過中央處理單元（CPU）中的錯誤報告機制捕獲，因此無法在硬體級別上進行跟蹤。但是，資料損壞在整個堆棧中傳播，並表現為應用程式級問題。這些類型的錯誤可能導致資料丟失，並且可能需要數月的偵錯工程時間。

在本文中，研究者描述了導致 SDC 的矽製造過程中常見的缺陷類型。討論了一個數據中心應用程式中靜默資料損壞的真實示例。並提供了一個偵錯案例，以通過案例研究來跟蹤 CPU 中的根本原因和對錯誤指令進行分類，以舉例說明如何偵錯此類錯誤。研究者提供了緩解措施的高階概述，以減少大型生產團隊中無提示資料損壞的風險。

論文雖然提出了緩解策略，但沒有解決根本原因。

論文地址：https://engineering.fb.com/2021/02/23/data-infrastructure/silent-data-corruption/

圖 2 以圖形形式顯示了資料庫的損壞和連結。

圖 3 提供了一個高階偵錯流程，用於追蹤導致根本原因的靜默錯誤。損壞也會影響非零的計算。例如，在被識別為有缺陷的機器上執行了以下不正確的計算。研究發現計算會影響特定資料值的正負冪，並且在某些情況下，結果應該為零時卻非零。以不同的精度獲得了不正確的值。

錯誤示例

在谷歌的研究人員看來，Facebook 發現了靜默錯誤，但是找出錯誤原因並解決它，還需要進一步的工作。

不正常的核心帶來的風險不僅包括崩潰（現有的錯誤處理故障停止模型可以適應這種情況），還涉及錯誤計算和資料丟失，這些問題可能被忽視，帶來風險。

Hochschild 講述了一個例子，「我們的一個 mercurial cores 破壞了加密，只有它才能解密自己錯誤加密的內容。」谷歌的研究人員以「商業原因」拒絕透露其資料中心檢測到的 CEE 率，但他們提供了一個大致的數字，即大約是每幾千臺機器有幾個 mercurial cores，與 Facebook 報告的比率類似。

理想情況下，谷歌希望看到自動識別 mercurial cores 的方法，並建議在晶片的整個生產週期中進行 CPU 測試，而不是僅僅依賴於部署前的老化測試。目前，谷歌依賴於人工驅動的核心完整性審查，但這種方式並不是特別準確，識別可疑核心的工具和技術仍在進行中。

谷歌的研究人員解釋說，「根據我們最近的經驗，通過人工驅動審查發現的可疑性錯誤，大約有一半是被證實的，我們必須通過進一步的測試 (通常是在首先開發一種新的自動測試之後) 來提取『證據』」。另一半是虛假指控和有限的可復現性。