共计 1412 个字符，预计需要花费 4 分钟才能阅读完成。
上周，CrowdStrike 的错误更新导致全球范围内的 Windows 系统出现大规模蓝屏事件，造成巨大经济损失。
据估计，仅美国财富 500 强企业就面临 54 亿美元的损失，全球损失可能高达 150 亿美元。受此影响，CrowdStrike 股价暴跌超过 20%。
除了对 CrowdStrike 的质疑和谴责，开发者圈内还兴起了另一个话题：
”如果 CrowdStrike 改用 Rust 的话，全球 850 万 PC 是不是就不会蓝屏了？“
这次事件的起因竟是一个简单的 null deref 错误。尽管 C ++ 语言已经发展了数十年，拥有各种工具、linter、sanitizer、测试和同行评审机制，但仍然无法阻止此类错误的发生。
因此不少开发者认为，如果采用内存安全机制更完善的 Rust 语言，或许能够避免类似事件的发生。
然而，一位同样喜欢 Rust 的资深软件工程师 Julio Merino，在理智地进行了一番全盘分析后得出结论：“就算是 Rust，也救不了这次 CrowdStrike 的中断事故。”
我们来看看他怎么说。
首先，CrowdStrike 官方将此次事件归咎于一次配置更新引发的逻辑错误，该错误导致部分系统崩溃。
具体来说，Falcon 平台在解析配置文件时，由于代码逻辑缺陷，尝试访问了无效的内存地址，最终引发系统崩溃。
诚然，Rust 的内存安全机制可以有效避免此类内存访问错误。然而，将此次事件仅仅归咎于内存安全问题，无异于“只见树木，不见森林”。
首先，内核崩溃的原因多种多样，内存错误只是其中之一。
死锁、系统调用处理程序错误、无限递归等等，都可能导致内核崩溃。Rust 虽然可以最大程度减少内存错误和其他逻辑错误，但并不能完全杜绝所有潜在问题。
其次，即使 Falcon 不运行在内核空间，系统崩溃的风险依然存在。
Falcon 作为终端安全系统，需要具备防篡改能力，以防止恶意软件和用户的恶意操作。如果将 Falcon 迁移至用户空间，并通过受控 API 与内核通信，则需要确保这些 API 同样具备防篡改能力。
否则，恶意软件或用户可以通过攻击这些 API，间接地影响系统稳定性。
因此，仅仅依靠 Rust 的内存安全机制，并不能完全避免类似事件的发生。
更重要的是，此次事件的根本原因在于 CrowdStrike 的配置变更发布流程存在严重缺陷。
根据 SRE 原则，配置变更应该分阶段、渐进式地进行，并在每个阶段进行充分验证。
然而，CrowdStrike 显然没有遵循这一原则，导致一个本应在测试阶段就被发现的错误配置被推送至全球用户，最终引发了大规模系统崩溃。
CrowdStrike 最新发布的初步审查报告也证实了这一点，报告指出“测试和流程不完善”是导致此次事件的主要原因。
报告详细描述了从 2 月 28 日到 7 月 19 日期间，CrowdStrike 多次发布更新，并在测试环节存在严重疏漏，最终导致了 7 月 19 日的全球宕机事件。
综上，CrowdStrike 全球宕机事件的根本原因在于其部署流程的缺陷，而非简单的代码或技术问题。
——-
将 Rust 奉为解决此类问题的唯一答案，不仅无助于问题的解决，反而会加剧技术社区之间的分歧，不利于 Rust 的推广和普及。
我们应该认识到，任何技术都有其局限性，Rust 也不是万能的。
与其盲目追捧，不如理性看待，将 Rust 作为提升软件安全性和可靠性的工具之一，并结合完善的流程和最佳实践，共同构建更加健壮的软件系统。
原文地址: 用 Rust 重写 Windows，能阻止 150 亿美元的蓝屏惨案吗？
