編譯 | 鄭麗媛
出品 | CSDN（ID：CSDNnews）
距離 Windows 大範圍藍屏事件，已經過去了 6 天。
這 6 天來，國内外技術網站仍對此事熱議不斷，“罪魁禍首” CrowdStrike 的名字被頻繁提及，與之伴随的無一不是質疑和譴責：
- CrowdStrike 引發的系統故障導緻數千架航班停飛、醫院癱瘓、支付系統崩潰，被專家稱為史上最大的 IT 故障。
- 據 Parametrix 保險公司稱，CrowdStrike 錯誤更新引發的全球技術中斷，使美國财富 500 強企業（不包括微軟）面臨 54 億美元的經濟損失，全球經濟損失總額可能達到 150 億美元左右。
基于此，本周 CrowdStrike 的股價已迅速暴跌超 20%。出于對引發此次故障的歉意，據悉昨日 CrowdStrike 還向其合作方均提供了一張價值 10 美元的 Uber Eats 禮品卡作為道歉：“為了表達我們的歉意，你的下一杯咖啡或宵夜由我們請客！”不過，有收到該禮品卡的使用者表示，他們去兌換時，頁面提示稱該禮品卡“已被發行方取消，不再有效”。
除了以上聚焦于 CrowdStrike 本身的關注和報道，近日還有一個話題也在開發者圈内引起了不小的讨論：”如果 CrowdStrike 改用 Rust 的話，全球 850 萬 PC 是不是就不會藍屏了？“
我驚訝地發現，過去幾天發生的所有事情都是由 deref 這樣簡單的錯誤引起的。數十年來，業界一直在使用 C++，所有的工具、linters、sanitizers、測試和同行評審都不足以避免這種情況的發生。是以我在想，如果改用 Rust，情況是否會大不一樣？
不僅如此，微軟 Azure 部門 CTO Mark Russinovich 也在事發後轉了一條他 釋出于 2022 年的推文：“說到語言，現在是時候停止用 C/C++ 啟動任何新項目了，請在需要使用非 GC 語言的情況下使用 Rust。為了安全性和可靠性，業界應該宣布這些語言已被淘汰。”
眼看着不少 Rust 狂熱愛好者開始放話“沒錯，Rust 就是唯一答案”，一位同樣喜歡 Rust 的資深軟體工程師 Julio Merino，在理智地進行了一番全盤分析後得出結論：“就算是 Rust，也救不了這次 CrowdStrike 的中斷事故。”
以下為譯文：
我非常喜歡 Rust，也很贊同不應繼續使用 C++ 這類記憶體不安全的程式設計語言，但我還是要說：那些聲稱用 Rust 就可以避免上周五全球大面積網絡中斷的說法太誇張了，對 Rust 的口碑有害無益。
如果 CrowdStrike 是用 Rust 編寫的，那确實可以降低發生故障的可能性，但它并不能解決導緻故障發生的根本原因。是以看到許多人說 Rust 是解決這次事故的唯一答案，我就感到非常惱火——這種說法，不僅無法推動 Rust 的普及，反而會招來反感：C++ 專家們都知道本次事故的根本原因，看到這種誤導性說法必然不快，進而導緻系統程式設計世界的進一步分裂。
那麼，為什麼說 Rust 不能解決這個問題呢？接下來我會試着回答這個問題，同時也深入探讨一下造成這次故障的原因。
故障分析
以下是來自 CrowdStrike 官方的“事後分析”：
在 2024 年 7 月 19 日 04:09 UTC，作為持續營運的一部分，CrowdStrike 向 Windows 系統釋出了傳感器配置更新。傳感器配置更新是 Falcon 平台保護機制的持續組成部分。此配置更新觸發了邏輯錯誤，導緻受影響的系統崩潰和藍屏（BSOD）
導緻系統崩潰的傳感器配置更新，已于 2024 年 7 月 19 日 05:27 UTC 得到修複。
把上面這段話翻譯為“人話”，就是：
1、CrowdStrike 公司推送了一項配置更新。
2、該更新觸發了“Falcon 平台”中的一個潛在 bug。
3、Falcon 中的這個 bug 導緻了 Windows 崩潰。
前兩點并不奇怪：對于任何線上系統來說，變更配置都是“家常便飯”，而這些更新引發代碼中的 bug 也是常見現象。事實上，大多數當機事件都是由人為配置變更造成的。
顯然，我們應該問問為什麼這個 bug 會存在，以及如何修複它以提高産品的穩定性。但我們别忘了第三點：為什麼這個 bug 能夠導緻整台機器癱瘓？更重要的是，為什麼這個 bug 會讓全球如此多的系統當機？
記憶體錯誤
讓我們從第一個問題開始：Falcon 中的 bug 是什麼性質的？
很簡單：在“Channel Files”（又稱配置檔案）解析器中存在一個邏輯錯誤，當遇到一些無效輸入時，這段代碼會試圖通路一個無效的記憶體位置。具體細節并不重要：可能是取消引用空指針，也可能是一般保護故障等等。關鍵在于：崩潰是由無效記憶體通路問題引發的。
這時，一些 Rust 狂熱粉可能會跳出來說：：“看啊，果然！如果代碼是用 Rust 寫的，這個 bug 就不會存在！”我無法否認這個說法：如果用 Rust，這個特定的 bug 确實不會出現。
但那又怎樣？就算避免了這種類型的 bug，下一次遇到 Rust 也無法避免的 bug 時，該當機還是會當機——無視 Falcon 的本質問題、隻關注記憶體錯誤的行為，好比“隻見樹木，不見森林”。
那麼，Falcon 究竟是什麼呢？
核心崩潰
在我看來，Falcon 是一種“惡意軟體......不過是好人的惡意軟體”，也就是一個終端安全系統。Falcon 通常安裝在企業機器上，以便安全團隊能夠實時檢測并解除威脅（同時監控員工的行為）。這确實有一定價值：大多數網絡攻擊都是通過社會工程學手段從入侵企業機器開始的。
這種類型的産品必須對機器有控制權，它必須能夠攔截所有使用者的檔案和網絡操作以掃描其内容，并且還必須是防篡改的，以防“精明”的企業使用者在閱讀到一些網上修複 WiFi 的可疑指導後嘗試禁用它，以避免送出 IT 工單。
如何實作像 Falcon 這樣的産品？最簡單的方法，也是 Windows 鼓勵的方法，就是編寫一個核心子產品。很明顯，Falcon 是一個核心子產品，是以它運作在核心空間。這就意味着，Falcon 代碼中的任何錯誤都可能破壞正在運作的核心，進而導緻整個系統崩潰。
我所說的“任何錯誤”，是真的。核心不僅會因為記憶體錯誤而崩潰，也不一定非要“核心崩潰”才能讓機器無法使用：死鎖會讓阻止核心前進，系統調用處理程式中的邏輯錯誤會阻止使用者空間之後打開任何檔案，一個無限遞歸算法會耗盡核心的堆棧……破壞核心穩定性的方法實在是太多了，是以我說就算是 Rust 也不能完全避免這種事故的發生。
Rust 的記憶體安全性隻能解決一種類型的崩潰。另外，Rust 生态系統中對正确性的關注也确實可以最大限度地減少其他類型邏輯錯誤的出現。但是……雖然我們都希望做到完美，但也必須接受錯誤會發生的事實——斷言 Rust 是解決問題的唯一答案和堅持使用 C++ 一樣，都是不負責任的行為。
要知道，在核心空間工作的 C++ 開發者，要比了解核心内部結構的 Rust 開發者多得多。是以，大部分 C++ 開發者都知道這種說法的可笑之處，同時也會增加兩個社群之間的敵意，更是完全違背了讓人們轉向安全語言的這個目标。Rust 開發者知道 Rust 确實可以改善現狀，但 C++ 開發者無法接受，因為他們聽到的觀點無法引起他們的共鳴。
從核心空間到使用者空間
還有人說，如果 Falcon 不在核心中運作，就根本不會發生這種情況。嗯，這個說法要好一點，但……僅此一點也不一定就能解決問題。
正如我之前提到的，Falcon 需要盡可能防篡改，防止惡意軟體對其進行幹擾，并防止被入侵的使用者試圖禁用它。如果惡意軟體或人類能夠輕易做到這一點，那麼這個産品就毫無用處。
現在，Windows 核心完全有能力禁止類似 Falcon 的核心子產品。相反，核心可以暴露一系列 API，讓使用者空間的應用程式能夠接入這些 API 來提供類似的功能。你知道嗎，微軟确實嘗試過讓 Windows 朝這個方向發展，但防毒軟體公司威脅要以反壟斷為由起訴，結果整個計劃無疾而終。是以，我們現在隻能忍受一個安全性較低的系統，因為防毒軟體公司需要銷售那些煩人的産品。
但是，我們先暫時放下這個麻煩不談。即使 Falcon 運作在使用者空間，并通過受控 API 與核心通信……這就足以防止系統故障嗎？請注意，這些 API 也需要防篡改。試想一下，如果你希望這個使用者空間驅動程式在核心執行每個二進制檔案之前進行驗證，也就是讓核心在每次執行時都需要從使用者空間驅動程式獲得答案，而這個驅動程式又有問題，那麼系統将無法再執行任何程式。
可如果你讓核心與驅動程式通信變成可選項，以便核心可以容忍崩潰的驅動程式，那麼就等于給惡意軟體開了一條路，它們可以先嘗試崩潰驅動程式，然後再入侵系統。
是以，僅僅“遷移到使用者空間”顯然也不是解決辦法。
部署中的漏洞
如果我們必須接受 bug 的存在，而記憶體相關的 bug 并不是唯一會導緻系統崩潰的原因，且将驅動程式移到使用者空間也不是很好的解決方案……那難道就無計可施了？真的沒有辦法防止這種情況發生嗎？
以上我說的這些，都是可以（也應該）采取的措施，以減少系統故障發生的機率，但我們必須接受這樣一個事實：這次代碼 bug 隻是特定的觸發因素，就算換一個觸發因素也可能會産生類似的惡果。本次全球當機事件的根本原因，在于配置變更的釋出流程。
根據 SRE 101（或 DevOps，随便你怎麼叫）規定，配置變更必須分階段進行，以緩慢和受控的方式部署，并在每個步驟進行驗證。這些變更應該先在很小的範圍内進行驗證，然後再向全球推送，而且每次推送都應是漸進的。
考慮到 Falcon 的關鍵性以及 bug 可能帶來的巨大影響，我很難相信 CrowdStrike 沒有對部署進行任何驗證。但根據 CrowdStrike 最新更新的事後分析來看，他們确實沒有進行任何形式的測試或金絲雀部署（在将更改推廣到整個服務叢集之前，先把更改推廣到一小部分使用者進行測試），這實在是令人難以置信的疏忽。
是以說，CrowdStrike 的部署實踐是造成此次事件的罪魁禍首——也就是說，這次當機事件是一個流程問題，而不是代碼或技術問題，改用 Rust 也無濟于事。
CrowdStrike 釋出初步審查報告，總結：“測試和流程不完善”
誠然如 Julio Merino 所說，CrowdStrike 在其官網最新釋出了此事件的初步審查報告，并公開了此次事件的整體時間線：
- 安全故障始于 2 月 28 日，當時 CrowdStrike 開發并分發了一個 Falcon 傳感器更新，旨在檢測一種新興的、利用 Windows 命名管道的攻擊技術，而傳感器更新在釋出前通過了正常測試。
- 3 月 5 日，該更新接受了壓力測試并得到驗證，可以投入使用。是以，當天 CrowdStrike 就向使用新的惡意命名管道檢測的客戶分發了快速響應更新。
- 在 4 月 8 日-4 月 24 日期間，CrowdStrike 又推送了三次使用這種新代碼模闆的快速響應更新，并表示所有這些更新“在生産環境中按預期運作”。
- 到了 7 月 19 日，CrowdStrike 又用 3 月份的傳感器模闆釋出了兩個快速響應更新，但這次其中一個更新推送的資料格式不正确。然而，CrowdStrike 用于檢查内容更新是否按預期運作的驗證系統有問題，它沒有發現這個要推送給所有人的配置檔案存在錯誤。于是乎，這個本該停止釋出的錯誤更新就造成了全球 850 萬 PC 藍屏。
部分網友在看過 CrowdStrike 這份冗長的初步審查報告後，精辟總結：“說了這麼多，就是想說我們的測試和流程不完善，不小心把垃圾釋出出來了”；“字數驚人，但歸根結底還是測試代碼有 bug 以及測試不夠”；“不好意思，我們對此更新進行的唯一測試，是一個沒真正通過的自動化測試”。
是以對于這種事故原因，絕對不是改用 Rust 就能解決的，根本還是在于測試環節和部署流程的不規範。與此同時，CrowdStrike 也在事後總結中表示，今後要在釋出更新前增加軟體測試，并逐漸推出更新，具體補救措施大體分為三個部分：
1、軟體彈性和測試
（1）通過使用以下測試類型改進快速響應内容測試：本地開發人員測試，内容更新和復原測試，壓力測試、模糊測試和故障注入，穩定性測試和内容接口測試；
（2）在快速反應内容的驗證器中增加額外的驗證檢查；
（3）增強内容解釋器中現有的錯誤處理功能。
2、快速響應内容部署
（1）對快速響應内容實施交錯部署政策，從金絲雀部署開始，再逐漸将更新部署到更大的區域；
（2）改進對傳感器和系統性能的監控，在快速響應内容部署期間收集回報資訊，以指導分階段部署；
（3）允許使用者選擇部署的時間和位置，使其能夠更好地控制快速響應内容更新的傳遞；
（4）通過客戶可訂閱的釋出說明提供内容更新詳情。
3、第三方驗證
（1）進行多個獨立的第三方安全代碼審查；
（2）對從開發到部署的端到端品質流程進行獨立審查。
參考連結：
https://www.crowdstrike.com/falcon-content-update-remediation-and-guidance-hub/
https://blogsystem5.substack.com/p/crowdstrike-and-rust
大模型重新整理一切，讓我們有着諸多的迷茫，AI 這股熱潮究竟會推着我們走向何方？面對時不時一夜變天，焦慮感油然而生，開發者怎麼能夠更快、更系統地擁抱大模型？《新程式員 007》以「大模型時代，開發者的成長指南」為核心，希望撥開層層迷霧，讓開發者定下心地看到及擁抱未來。
讀過本書的開發者這樣感慨道：“讓我驚喜的是，中國還有這種高品質、貼近開發者的雜志，我感到非常激動。最吸引我的是裡面有很多人對 AI 的看法和經驗和一些采訪的内容，這些内容既真實又有價值。”