当呼吁起不到实际的效果时，美国政府机构又想出一个提高内存安全编程措辞利用率的新方法。
近日，有不少人创造，美国国防高等研究操持局（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 代码中的缺点，而要冒险重写它呢？”
对此，你怎么看？
参考：
https://www.darpa.mil/news-events/2024-07-31a
https://news.ycombinator.com/item?id=41110269
https://www.theregister.com/2024/08/03/darpa_c_to_rust/