用Rust重寫Windows，能阻止150億美元的藍屏慘案嗎？

上周，CrowdStrike的錯誤更新導(dǎo)致全球范圍內(nèi)的Windows系統(tǒng)出現(xiàn)大規(guī)模藍屏事件，造成巨大經(jīng)濟損失。

據(jù)估計，僅美國財富500強企業(yè)就面臨54億美元的損失，全球損失可能高達150億美元。受此影響，CrowdStrike股價暴跌超過20%。

除了對CrowdStrike的質(zhì)疑和譴責(zé)，開發(fā)者圈內(nèi)還興起了另一個話題：

”如果CrowdStrike改用Rust的話，全球850萬PC是不是就不會藍屏了？“

這次事件的起因竟是一個簡單的null deref錯誤。盡管C++語言已經(jīng)發(fā)展了數(shù)十年，擁有各種工具、linter、sanitizer、測試和同行評審機制，但仍然無法阻止此類錯誤的發(fā)生。

因此不少開發(fā)者認為，如果采用內(nèi)存安全機制更完善的Rust語言，或許能夠避免類似事件的發(fā)生。

然而，一位同樣喜歡Rust的資深軟件工程師Julio Merino，在理智地進行了一番全盤分析后得出結(jié)論：“就算是Rust，也救不了這次CrowdStrike的中斷事故。”

我們來看看他怎么說。

首先，CrowdStrike官方將此次事件歸咎于一次配置更新引發(fā)的邏輯錯誤，該錯誤導(dǎo)致部分系統(tǒng)崩潰。

具體來說，F(xiàn)alcon平臺在解析配置文件時，由于代碼邏輯缺陷，嘗試訪問了無效的內(nèi)存地址，最終引發(fā)系統(tǒng)崩潰。

誠然，Rust的內(nèi)存安全機制可以有效避免此類內(nèi)存訪問錯誤。然而，將此次事件僅僅歸咎于內(nèi)存安全問題，無異于“只見樹木，不見森林”。

首先，內(nèi)核崩潰的原因多種多樣，內(nèi)存錯誤只是其中之一。

死鎖、系統(tǒng)調(diào)用處理程序錯誤、無限遞歸等等，都可能導(dǎo)致內(nèi)核崩潰。Rust雖然可以最大程度減少內(nèi)存錯誤和其他邏輯錯誤，但并不能完全杜絕所有潛在問題。

其次，即使Falcon不運行在內(nèi)核空間，系統(tǒng)崩潰的風(fēng)險依然存在。

Falcon作為終端安全系統(tǒng)，需要具備防篡改能力，以防止惡意軟件和用戶的惡意操作。如果將Falcon遷移至用戶空間，并通過受控API與內(nèi)核通信，則需要確保這些API同樣具備防篡改能力。

否則，惡意軟件或用戶可以通過攻擊這些API，間接地影響系統(tǒng)穩(wěn)定性。

因此，僅僅依靠Rust的內(nèi)存安全機制，并不能完全避免類似事件的發(fā)生。

更重要的是，此次事件的根本原因在于CrowdStrike的配置變更發(fā)布流程存在嚴重缺陷。

根據(jù)SRE原則，配置變更應(yīng)該分階段、漸進式地進行，并在每個階段進行充分驗證。

然而，CrowdStrike顯然沒有遵循這一原則，導(dǎo)致一個本應(yīng)在測試階段就被發(fā)現(xiàn)的錯誤配置被推送至全球用戶，最終引發(fā)了大規(guī)模系統(tǒng)崩潰。

CrowdStrike最新發(fā)布的初步審查報告也證實了這一點，報告指出“測試和流程不完善”是導(dǎo)致此次事件的主要原因。

報告詳細描述了從2月28日到7月19日期間，CrowdStrike多次發(fā)布更新，并在測試環(huán)節(jié)存在嚴重疏漏，最終導(dǎo)致了7月19日的全球宕機事件。

綜上，CrowdStrike全球宕機事件的根本原因在于其部署流程的缺陷，而非簡單的代碼或技術(shù)問題。

-------

將Rust奉為解決此類問題的唯一答案，不僅無助于問題的解決，反而會加劇技術(shù)社區(qū)之間的分歧，不利于Rust的推廣和普及。

我們應(yīng)該認識到，任何技術(shù)都有其局限性，Rust也不是萬能的。

與其盲目追捧，不如理性看待，將Rust作為提升軟件安全性和可靠性的工具之一，并結(jié)合完善的流程和最佳實踐，共同構(gòu)建更加健壯的軟件系統(tǒng)。