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 測試，而不是僅僅依賴于部署前的老化測試。目前，谷歌依賴于人工驅動的內核完整性審查，但這種方式并不是特別準確，識別可疑內核的工具和技術仍在進行中。

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