当呼吁起不到实际的效果时，美国政府机构又想出一个提高内存安全编程语言使用率的新方法。
近日，有不少人发现，美国国防高级研究计划局（DARPA）正在启动一项资助计划，即推动一款程序代码转换工具 TRACTOR（全称为 Translating All C to Rust）的开发，旨在借助 AI 大模型技术独立地将传统的 C 和 C++ 代码直接转换为可用的 Rust 代码。
同时，DARPA 最终希望这款 AI 工具达到的水平能够与经验丰富的 Rust 程序员带来的结果相当，实现“一劳永逸地消除内存安全漏洞”。
呼吁开发者放弃 C、C++ 的机构们！
毋庸置疑，将 C、C++ 和 Rust 这几种语言摆在一起，DARPA 必然要提到内存安全问题。
在公告中，DARPA 指出，内存安全漏洞是已披露的软件漏洞中最常见的类型，主要通过两种方式影响计算机内存：
首先，C 语言等编程语言允许程序员直接操作内存，因此很容易在程序中意外引入错误，使看似常规的操作破坏内存状态。
其次，当我们在编写代码时，有时候会遇到一种叫做“未定义行为”的情况。就是说，编程语言的规则（或者标准）没有明确说明在某些特定情况下程序该怎么运行。所以，如果我们写的代码触发了这些不明确的情况，程序可能会以一种我们意想不到的方式运行，甚至可能导致内存安全问题（比如程序崩溃或产生错误结果）。
正因此，过去几年间，美国各大组织的呼吁动作不断，如我们此前报道的：
2022 年 11 月，美国国家安全局（NSA）发布了关于保护软件开发者和运营商免受内存安全问题影响的指南，列举了微软在 2006 年到 2018 年期间，发现的 70% 的漏洞都是因内存安全问题造成的；Google Chrome 中存在了类似比例的内存安全漏洞...鼓励多个组织将编程语言从 C/C++ 转为使用内存安全的语言，如 C#、Rust、Go、Java、Ruby 和 Swift，称这样可以帮助软件开发者和使用者预防并缓解软件内存安全问题；
彼时，微软 Azure CTO Mark Russinovich 也呼吁，「是时候停止使用 C/C++ 启动任何新项目」。
2023 年 12 月，美国网络安全和基础设施局 (CISA)也开始联合 NSA、美国联邦调查局 (FBI) 以及澳大利亚、加拿大、英国和新西兰的网络安全机构发布了一份 23 页的《内存安全路线图指南》，直接点名 C 和 C++ 是内存不安全的语言代表，软件开发商应该放弃使用，从而迅速采用 Rust、C#、Go、Java、Python 和 Swift 等其他内存安全编程语言 (MSL)。
2024 年 2 月，美国白宫国家网络主任办公室 (ONCD)在一份主题为《回到基础构件：通往安全软件之路》的 19 页 PDF 报告中再次强烈呼吁道，“C、C++ 不安全，新应用开发时就别用了，旧应用应该采取迁移行动”。
2024 年 7 月，美国网络安全部门（CISA）联合美国联邦调查局（FBI）、澳大利亚信号局（ASD）、澳大利亚网络安全中心（ACSC）和加拿大网络安全中心（CCCS）共五大机构发布了一份 22 页的调查报告——《探索关键开源项目中的内存安全》，发现 172 个项目中有 52% 是使用 C、C++ 和其他所谓“内存不安全”的语言编写的，希望引发众人的重视。
在连番呼吁之下，内存安全问题确实引起了一定的重视。为此，一些组织也开始了行动，如：
互联网安全研究小组的 Prossimo 项目与 weedegolf 合作，用 Rust 重写 Network Time Protocol (NTP) ，以提供内存安全的 NTP。
早些时候，苹果公司修改了用于构建 iBoot 引导载入程序的 C 编译器工具链，以减少内存和类型安全问题。
有消息称，微软已经用 3.6 万行 Rust 代码改写了 Windows 内核；
2022 年 12 月，Linux 内核 6.1 发布，包含了初始 Rust 支持...
然而，摆在现实中的问题是，即使当代开发者深谙要在编写程序的时候尽可能地使用内存安全的语言，也做了如上所述的一些尝试，但要知道 C 语言诞生于 20 世纪 70 年代，发展至今已经五十多年的历史，早已变得无处不在，无论是现代智能手机，还是太空飞行器等各种应用程序，都有它的身影。
就连 DARPA 也坦言，美国国防部的长寿命系统对 C 语言等编程语言的依赖程度更高。
手动地一行一行改写代码，亦或者正确遵守 ISO 标准并认真应用测试工具就可以避免安全漏洞，显然有些不太现实。
DARPA 也得出了一个结论：经过二十多年对 C 和 C++ 内存安全问题的努力，软件工程社区已达成共识，仅仅依靠错误查找工具是不够的。
迁移是巨大的问题
然而此前，美国政府机构在发出呼吁的同时也指出，向 MSL（内存安全语言）过渡将涉及重大投资和高管关注，此外任何此类过渡都需要多年的精心规划。
因此，虽然内存安全编程语言可以消除内存安全漏洞已经不是什么秘密，但面临的挑战一直是如何大规模重写传统代码，以应对庞大的问题。要想弃用，不谈迁移代码带来的技术难度问题，仅是外在的人力、财力、精力成本都大到难以想象。
时下，始于大型语言模型 (LLM) 等机器学习技术的最新突破，DARPA 表示这创造了一种新解决方案的环境，即“通过大规模自动化，将世界上高度脆弱的遗留 C 代码自动转换成本质上更安全的 Rust 编程语言。”
“你可以访问任何 LLM 网站，开始与其中一个 AI 聊天机器人聊天，你只需要说‘这是一些 C 代码，请将其转换成安全的 Rust 代码’，然后剪切、粘贴，就会出现一些结果，而且通常效果很好。”DARPA TRACTOR 项目经理 Dan Wallach 博士说。
不过，这是理想状态下的情况，Dan Wallach 表示，“但现实并非总是如此，研究挑战在于大幅改进从 C 到 Rust 的自动转换，特别是对于最相关的程序结构。”
TRACTOR 的目标不仅是实现代码转换的自动化，而且要实现熟练开发人员手动编写 Rust 代码的高质量和风格。
通过这样做，该计划旨在消除 C 程序中固有的内存安全漏洞。除了利用软件分析方法（包括静态和动态分析）外，TRACTOR 还将采用 LLM 支持的解决方案并举办公开竞赛来展示和测试这些创新。
Wallach 表示，“Rust 迫使程序员把事情做好，处理它强制执行的所有规则可能会让人感到束缚，但当你适应它们时，这些规则会给你自由。它们就像护栏；一旦你意识到它们是用来保护你的，你就会自由地专注于更重要的事情。”
当前，DARPA 已经公开发布了这一计划，也希望有更多的参赛者参与进来提交关于 LLM 支持的解决方案。DARPA 将于 2024 年 8 月 26 日举办一场活动，针对计划为 TRACTOR 项目提交提案的人。这个活动可以亲自参加，也可以远程参加。不过，想要参加这个活动的人必须在 8 月 19 日之前进行注册（https://sam.gov/opp/1e45d648886b4e9ca91890285af77eb7/view）。
AI 能一键实现 C、C++ 代码转换成 Rust 代码吗？
从内存安全出发，借助 AI 大模型的潜力，实现不同的语言代码一键转换，确实是一个不错的想法。
据外媒 The Register 报道，Prossimo 项目执行董事 Josh Aas 对此认为，“当今互联网基础设施中运行的大量 C 代码使得使用翻译工具变得很有吸引力。我们已经对此进行了尝试，例如我们最近将基于 C 语言的 AV1 实现转换为 Rust。虽然目前的工具还需要不少手动调整才能让结果正确并符合惯用法，但我们相信，通过进一步投资，这些工具将会变得更加高效。”
理想情况下，只要用自然语言告诉 AI 将 C、C++ 遗留代码转为 Rust 代码，它确实会帮助转换，但是这样生成的结果是否可以直接使用？我们距离 TRACTOR 项目成为现实又还有多远？
正在负责 TRACTOR 项目的工作 Wallach 坦言，该项目的目标是实现高度自动化，但这需要克服一些棘手的技术挑战。
“其中一个挑战是，当你让大型语言模型（LLMs）转换代码时，它们有时能给出出乎意料的好答案，但也可能会产生错误的答案。另一个挑战是 C 语言允许代码对指针进行操作，包括算术运算，而 Rust 禁止这些操作。要弥合这一差距，不仅仅是把 C 语言直接转换成 Rust 这么简单。”
对于这一计划，开发者的看法不一。
网友 mike_heran 认为：
这听起来......很难。尤其是编写 Rust 与 C 语言的习惯完全不同，而且大多数有趣的代码都是用 C++ 编写的。
这不就等同于我们需要在静态分析中确定所有 C 程序中内存分配的生命周期，包括使用自定义分配器实现的分配，或者与专有库交互的分配？多年来，尽管人们对这个问题进行了大量研究，但并没有取得显著成果。C/C++ 程序可以做一些事情，比如将内存分配的生命周期与用户点击的按钮关联，而不是使用引用计数或其他机制来确保安全。虽然这不是一个好的做法，但它们确实可以这么做。
编写这种静态分析工具的另一个显著问题是，你所分析的程序本身可能是有漏洞的，生命周期分析可能没有意义（如果生命周期明确，就不会有内存安全漏洞，也就不需要替换）。我见过的关于静态检测生命周期问题的唯一研究，假定被分析的代码从一开始就是正确的。不过，你可以尝试开发一种程序，它能够检测出无法计算生命周期的地方，并向开发人员寻求帮助。
另一位开发者 blonk 表示：
「我个人并不认为这个项目有什么问题。问题更多在于“代码库有多大”以及“这真的是资源的最佳利用方式吗？”我敢打赌，他们之所以想使用 LLM，是因为他们要移植的代码量很大，所以他们想把这个过程自动化。如果是代码库庞大，那么我不确定使用 LLM 来加快进程是否是个好主意。
但这只是我的猜测。也有可能是这些项目历史上存在大量内存安全问题，而 Rust 可以捕捉到这些问题，在这种情况下，使用 LLM（有可能）是值得的。不管怎样，我相信几年后我们会知道更多关于这个项目是成功还是灾难的信息。」
还有用户 Rich 2 提出质疑：
“如果你能开发出将 C 代码转换为 Rust 的工具，那么倘若 C 代码确实包含内存错误，将会发生两种情况之一：
(a)工具会将这些错误一并转换到 Rust 中，但因为 Rust 的语言特性，理论上不应该发生这种情况，因为 Rust 不支持导致这些错误的结构。
(b) 工具会在转换过程中发现并报告这些错误。
如果是(a)，即工具只会复制错误，那转换并没有任何意义；如果是(b)，即工具会发现并报告错误，那么为什么不直接修复 C 代码中的错误，而要冒险重写它呢？”
对此，你怎么看？
