拜登政府喊话开发者：呼吁采用 Rust 以应对内存安全挑战

“程序员编写代码并非没有后果，他们的⼯作⽅式于国家利益而言至关重要。”白宫国家网络总监办公室（ONCD，以下简称网总办）在本周一发布的报告中说道。在该报告中，拜登政府希望软件开发人员尽量使用 Rust 这样的内存安全编程语言，并放弃 C 和 C++ 等安全性薄弱的语言。另外，参议院还强调会努力为内存安全立法。

这并不是拜登政府对内存安全语言的首次提倡。
美国网络安全与基础设施安全局（CISA）在去年 9 月的一篇博文中，也曾公开敦促开发人员使用内存安全编程语言。网络与基础设施安全局、联邦调查局（FBI）、国家安全局及各盟国机构随后于 12 月发布了题为《内存安全路线图案例》（The Case for Memory Safe Roadmaps）的研究报告，其中就点名 C/C++ 存在内存安全漏洞，软件开发商应放弃使用，改用 C#、Rust、Go、Java、Python 和 Swift 等内存安全的编程语言 (MSL)。

此外，早在 2022 年 11 月，国安局网络安全信息表就将 C#、Go、Java、Ruby、Swift 以及 Rust 列为认定的内存安全编程语言。

在这份 19 页的最新报告中，白宫则将 C 和 C++ 作为存在内存安全漏洞的两大编程语言示例，相应的内存安全正面典型则是 Rust 语言。

微软和谷歌最近的研究发现，约有 70% 的安全漏洞由内存安全问题引发。国家网络总监 Harry Coker 在白宫新闻稿中表示，“我们美国有能力、也有责任缩小网络空间的攻击面，并防止各类安全漏洞侵入数字生态系统。而这要求我们首先解决转向内存安全编程这一根本难题。”

白宫在一份新闻稿明确提出，科技企业可通过采用内存安全编程语言“防止各类漏洞侵入数字生态系统”。内存安全编程语言能够免受与内存访问相关的各类软件 bug 及漏洞的影响，具体包括缓冲区溢出、越界读取和内存泄漏。

白宫新闻稿提到，这份报告的目标之一是将网络安全责任从个人和小型企业，转移到大型组织、科技巨头及美国政府身上，因为后者“更有能力应对不断变化的威胁形势”。

网总办称其与科技企业、学术界及其他组织等私营部门合作制定了报告中的建议条款。网总办自去年 8 月起就该主题发出了公众意见征集请求，随后收集到多家科技企业的支持回应，包括 HPE、埃森哲和 Palantir。其他软件安全专家也对报告内容表示赞赏。

网总办公室还公布了报告筹备过程中征集到的意见：

然而，替代 C 和 C++ 绝不可能一蹴而就，特别是在嵌入式系统领域。

根据 Statista 公布的数据，截至 2023 年，约有 22% 的软件程序员仍在使用 C++，其中 19% 使用 C 语言，总体人气已经不及 JavaScript、Python、Java 等其他流行语言。但 TIOBE 编程社区指数榜则仅将 Python 列为流行度领先语言，紧随其后的分别是 C、C++ 和 Java。

Grossman 指出，“好消息是系统软件中其他语言、特别是 Rust 的应用已经显著增长，我发现人们普遍认为这种演变将进一步加速。而 C 和 C++ 开发的份额只会逐步降低，而非一夜之间遭到弃用，其巨大的业界整体影响力仍然存在。”

互联网安全研究小组执行董事兼联合创始人 Josh Aas 则补充称，放弃 C 和 C++ 将是一个“漫长且艰难的过程。改变人们思考事物的方式离不开持续努力，而现在这样的沟通有助于巩固安全问题在人们思维中的存在感和重要性。”

在 Aas 看来，要想推动这一变革，政府与私营部门间必须协同努力，将安全编码视为优先事项。

他总结道，“最终，我们必然要编写并部署新代码。但实现这个目标离不开资源的加持，我们必须保证从政府到私营部门的各级领导者，都将此视为高优先级工作。相关负责人应当意识到这个问题，并保证他们在解决问题的过程中能得到有力支持。”

那从技术角度看，用 Rust 重写大型 C/C++ 系统组件后就绝对安全了吗？答案是否定的。

本质上讲，Rust 和 C/C++ 是不能直接交互的——它们在类型、内存管理和控制流方面都采取了截然不同的方法。结果就是，如果手动编写“胶水”代码，就很可能打破隐式假设（例如调用约定和数据表示）、关键不变量（例如内存和类型安全、同步和资源处理协议），并跨过语言边界引入未定义的行为错误，例如展开恐慌（unwinding panics）、整型表示错误、为枚举和标记的联合体类型静默创建无效值等。

内存管理方法方面，Rust 的类型系统会静态跟踪对象的生命周期和所有权，C 语言要求程序员手动管理内存，而 C++ 虽然提供内存安全抽象，但也允许自由将其与原始指针加以混合。

更重要的是，在将 C/C++ 系统迁移至 Rust 时，开发者必须通过 FFI 层来协调这些差异，其困难程度可见一斑。例如，跨 FFI 边界共享指针会引发跨语言内存管理问题，其中一种语言分配的指针会被另一种语言所释放。而当 C 和 Rust 代码试图共享内存所有权时，情况将变得更为复杂。

与此同时，Rust 代码往往高度依赖类型系统所保证的不变量，借此确保内存安全和代码正确性。由于 C/C++ 程序通常不遵循相同的不变量，因此 C/C++ 在与 Rust 代码交互时可能引发冲突，这类问题在重写后尤其多见。

Rust 和 C 间的不匹配，往往导致 FFI 边界处出现大量不安全代码——这令开发者很难安全将组件移植为 Rust 形式。更要命的是，哪怕是精通 Rust 和 Modula 3 系统架构的开发者，也几乎无法回避这些麻烦。

另外，报告里也承认，“在某些特殊情况下，可能无法正常使用内存安全语言”。以太空系统为例，垃圾收集语言就无法满足其健壮性要求。报告还提到，Rust 虽具有必要的内存安全特性，但“尚未在太空系统中得到证实。”

值得注意的是，C++ 之父 Bjarne Stroustrup 在去年底参加“CppCon”C++ 会议时向观众承诺，他将首先明确该编程语言所需的安全措施的具体类型。

Stroustrup 给出的解决方案是配置文件（指的是需要遵循的一组规则，可以实现特定的安全保证），它们由 ISO C++ 标准定义，解决常见的安全问题，例如指针和数组范围。Stroustrup 的总体策略是，使用静态分析来消除潜在错误，但全局静态分析无法承受，所以需要一些规则来简化正在编写的内容，以便有效且廉价地进行本地静态分析，然后提供一些库来更好地依赖这些规则。

与此同时，虽然被公认为“安全语言”，但 Rust 在 2023 年除了提升性能和做规范化，也在努力进行安全性补齐短板。比如 Rust 通过支持更多安全编译场景如异步 trait 方法、优化编译告警等，优化了用户体验，使用户得以更好地获取 Rust 安全性的优点。