谷歌、Facebook頻繁發(fā)現(xiàn)CPU內(nèi)核不可靠，出現(xiàn)無法預(yù)測計算錯誤

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

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

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

谷歌工程師 Peter Hochschild 在近日剛剛舉辦的 HotOS 2021 上說道：「生產(chǎn)團隊抱怨『機器破壞數(shù)據(jù)』的情況越來越多。」他表示：「這些機器被指控破壞了多個不同的、穩(wěn)定的、調(diào)試良好的大型應(yīng)用程序。機器都被各個獨立團隊反復(fù)指責，并且這些指控是可信的。但傳統(tǒng)的診斷方法沒有發(fā)現(xiàn)它們有任何問題?！?/p>

開發(fā)者們更深入地查看了所涉及的代碼和來自相關(guān)機器的操作遙測，谷歌工程師開始懷疑是硬件存在問題。他們調(diào)查發(fā)現(xiàn)硬件錯誤的發(fā)生率高于預(yù)期，這些問題在安裝后很長時間內(nèi)偶爾會出現(xiàn)，并且出現(xiàn)在特定的單個 CPU 內(nèi)核上，而不是整個芯片或一系列部件上。

谷歌的研究人員檢查了這些靜默損壞執(zhí)行錯誤 (corrupt execution error，CEE) 后得出結(jié)論：這些錯誤應(yīng)該歸咎于「易變的內(nèi)核（mercurial core）」——CPU 在一些情況下偶爾會以一種無法預(yù)測的方式出現(xiàn)計算錯誤。

這些錯誤不是因為像 M1 芯片一樣的架構(gòu)設(shè)計失誤，而且在制造測試期間也沒有檢測到這些問題。相反，谷歌工程師認為，之所以會出現(xiàn)錯誤，是因為我們已經(jīng)將半導(dǎo)體制造推向了故障變得更加頻繁的地步，而我們?nèi)狈μ崆白R別故障的工具。

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

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

但該研究表示有一個更根本的原因：「越來越小的特征尺寸越來越接近 CMOS 縮放的極限，并且架構(gòu)設(shè)計的復(fù)雜性也在不斷增加?！共⒅赋霈F(xiàn)有的驗證方法并不適用于發(fā)現(xiàn)偶爾出現(xiàn)的缺陷或部署后物理損壞的結(jié)果。

我們習慣于將計算機視為故障停止裝置，尤其是執(zhí)行指令的內(nèi)核，而大多數(shù)系統(tǒng)軟件都依賴于這種假設(shè)。隨著芯片制造朝著更小的特征尺寸和更精細的計算結(jié)構(gòu)發(fā)展，并且隨著引入新的復(fù)雜指令集以提高性能，我們發(fā)現(xiàn)了在制造測試期間沒有檢測到的計算錯誤。這些缺陷不能總是通過微代碼更新等技術(shù)來緩解，并且這些缺陷可能與處理器內(nèi)的特定組件有關(guān)，允許小型代碼更改可能會影響可靠性。更糟糕的是，這些錯誤通常是悄無聲息的——唯一的變現(xiàn)就是出現(xiàn)計算錯誤。

這種「易變」的內(nèi)核極為罕見，但在大量服務(wù)器中，我們則可以觀察到它們造成的中斷，甚至足以將它們視為一個明顯的問題。這意味著需要硬件設(shè)計人員、處理器供應(yīng)商和系統(tǒng)軟件架構(gòu)師之間合作解決這種缺陷問題。

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

「易變」內(nèi)核的識別具有挑戰(zhàn)性，因為「易變」內(nèi)核可能導(dǎo)致故障和數(shù)據(jù)損壞、而不當?shù)淖R別可能會導(dǎo)致良好內(nèi)核的浪費，并且識別過程的成本也很高。該研究對「易變」內(nèi)核的識別過程進行了分類，包括：

自動化與人工；

部署前與部署后；

線下 vs. 線上； 

基礎(chǔ)設(shè)施級別與應(yīng)用級別。

不過，識別和去除「易變」內(nèi)核并不總是能避免影響應(yīng)用程序，并且識別可能不是完美的。因此谷歌的研究者提議設(shè)計能夠容忍 CEE 且沒有過多開銷的軟件？這將從以下幾點出發(fā)：

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

系統(tǒng)應(yīng)該支持高效的檢查點，通過在不同的內(nèi)核上重新啟動，以將失敗的計算重新恢復(fù)。

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

Facebook 也發(fā)現(xiàn)了同樣的問題

無獨有偶，F(xiàn)acebook 也注意到了這些錯誤。今年 2 月，F(xiàn)acebook 發(fā)表了一篇名為《 Silent Data Corruptions at Scale 》的論文，論文中寫到，與之前觀察到的數(shù)據(jù)中心相比，靜默數(shù)據(jù)損壞（SDC）正在成為一種更加普遍的現(xiàn)象。SDC 不能通過中央處理單元（CPU）中的錯誤報告機制捕獲，因此無法在硬件級別上進行跟蹤。但是，數(shù)據(jù)損壞在整個堆棧中傳播，并表現(xiàn)為應(yīng)用程序級問題。這些類型的錯誤可能導(dǎo)致數(shù)據(jù)丟失，并且可能需要數(shù)月的調(diào)試工程時間。

在本文中，研究者描述了導(dǎo)致 SDC 的硅制造過程中常見的缺陷類型。討論了一個數(shù)據(jù)中心應(yīng)用程序中靜默數(shù)據(jù)損壞的真實示例。并提供了一個調(diào)試案例，以通過案例研究來跟蹤 CPU 中的根本原因和對錯誤指令進行分類，以舉例說明如何調(diào)試此類錯誤。研究者提供了緩解措施的高級概述，以減少大型生產(chǎn)團隊中無提示數(shù)據(jù)損壞的風險。

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

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

圖 2 以圖形形式顯示了數(shù)據(jù)庫的損壞和鏈接。

圖 3 提供了一個高級調(diào)試流程，用于追蹤導(dǎo)致根本原因的靜默錯誤。損壞也會影響非零的計算。例如，在被識別為有缺陷的機器上執(zhí)行了以下不正確的計算。研究發(fā)現(xiàn)計算會影響特定數(shù)據(jù)值的正負冪，并且在某些情況下，結(jié)果應(yīng)該為零時卻非零。以不同的精度獲得了不正確的值。

錯誤示例

在谷歌的研究人員看來，F(xiàn)acebook 發(fā)現(xiàn)了靜默錯誤，但是找出錯誤原因并解決它，還需要進一步的工作。

不正常的內(nèi)核帶來的風險不僅包括崩潰（現(xiàn)有的錯誤處理故障停止模型可以適應(yīng)這種情況），還涉及錯誤計算和數(shù)據(jù)丟失，這些問題可能被忽視，帶來風險。

Hochschild 講述了一個例子，「我們的一個 mercurial cores 破壞了加密，只有它才能解密自己錯誤加密的內(nèi)容?！构雀璧难芯咳藛T以「商業(yè)原因」拒絕透露其數(shù)據(jù)中心檢測到的 CEE 率，但他們提供了一個大致的數(shù)字，即大約是每幾千臺機器有幾個 mercurial  cores，與 Facebook 報告的比率類似。

理想情況下，谷歌希望看到自動識別 mercurial cores 的方法，并建議在芯片的整個生產(chǎn)周期中進行 CPU 測試，而不是僅僅依賴于部署前的老化測試。目前，谷歌依賴于人工驅(qū)動的內(nèi)核完整性審查，但這種方式并不是特別準確，識別可疑內(nèi)核的工具和技術(shù)仍在進行中。

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

參考鏈接：https://www.theregister.com/2021/06/04/google_chip_flaws/