美國禁用C語言，政府機構(gòu)再想新招：開發(fā)AI工具，一鍵將舊的C代碼轉(zhuǎn)為Rust

因公眾號更改推送規(guī)則，請點“在看”并加“星標”第一時間獲取精彩技術分享

點擊關注#互聯(lián)網(wǎng)架構(gòu)師公眾號，領取架構(gòu)師全套資料 都在這里

0、2T架構(gòu)師學習資料干貨分

上一篇：2T架構(gòu)師學習資料干貨分享

大家好，我是互聯(lián)網(wǎng)架構(gòu)師！

出品 | CSDN   整理 | 蘇宓

當呼吁起不到實際的效果時，美國政府機構(gòu)又想出一個提高內(nèi)存安全編程語言使用率的新方法。

近日，有不少人發(fā)現(xiàn)，美國國防高級研究計劃局（DARPA）正在啟動一項資助計劃，即推動一款程序代碼轉(zhuǎn)換工具 TRACTOR（全稱為 Translating All C to Rust）的開發(fā)，旨在借助 AI 大模型技術獨立地將傳統(tǒng)的 C 和 C++ 代碼直接轉(zhuǎn)換為可用的 Rust 代碼。

同時，DARPA 最終希望這款 AI 工具達到的水平能夠與經(jīng)驗豐富的 Rust 程序員帶來的結(jié)果相當，實現(xiàn)“一勞永逸地消除內(nèi)存安全漏洞”。

呼吁開發(fā)者放棄 C、C++ 的機構(gòu)們！

毋庸置疑，將 C、C++ 和 Rust 這幾種語言擺在一起，DARPA 必然要提到內(nèi)存安全問題。

在公告中，DARPA 指出，內(nèi)存安全漏洞是已披露的軟件漏洞中最常見的類型，主要通過兩種方式影響計算機內(nèi)存：

• 首先，C 語言等編程語言允許程序員直接操作內(nèi)存，因此很容易在程序中意外引入錯誤，使看似常規(guī)的操作破壞內(nèi)存狀態(tài)。
• 其次，當我們在編寫代碼時，有時候會遇到一種叫做“未定義行為”的情況。就是說，編程語言的規(guī)則（或者標準）沒有明確說明在某些特定情況下程序該怎么運行。所以，如果我們寫的代碼觸發(fā)了這些不明確的情況，程序可能會以一種我們意想不到的方式運行，甚至可能導致內(nèi)存安全問題（比如程序崩潰或產(chǎn)生錯誤結(jié)果）。

正因此，過去幾年間，美國各大組織的呼吁動作不斷，如我們此前報道的：

• 2022 年 11 月，美國國家安全局（NSA）發(fā)布了關于保護軟件開發(fā)者和運營商免受內(nèi)存安全問題影響的指南，列舉了微軟在 2006 年到 2018 年期間，發(fā)現(xiàn)的 70% 的漏洞都是因內(nèi)存安全問題造成的；Google Chrome 中存在了類似比例的內(nèi)存安全漏洞...鼓勵多個組織將編程語言從 C/C++ 轉(zhuǎn)為使用內(nèi)存安全的語言，如 C#、Rust、Go、Java、Ruby 和 Swift，稱這樣可以幫助軟件開發(fā)者和使用者預防并緩解軟件內(nèi)存安全問題；

• 彼時，微軟 Azure CTO Mark Russinovich 也呼吁，「是時候停止使用  C/C++ 啟動任何新項目」。
  
• 2023 年 12 月，美國網(wǎng)絡安全和基礎設施局 (CISA)也開始聯(lián)合 NSA、美國聯(lián)邦調(diào)查局 (FBI) 以及澳大利亞、加拿大、英國和新西蘭的網(wǎng)絡安全機構(gòu)發(fā)布了一份 23 頁的《內(nèi)存安全路線圖指南》，直接點名 C 和 C++ 是內(nèi)存不安全的語言代表，軟件開發(fā)商應該放棄使用，從而迅速采用 Rust、C#、Go、Java、Python 和 Swift 等其他內(nèi)存安全編程語言 (MSL)。
• 2024 年 2 月，美國白宮國家網(wǎng)絡主任辦公室 (ONCD)在一份主題為《回到基礎構(gòu)件：通往安全軟件之路》的 19 頁 PDF 報告中再次強烈呼吁道，“C、C++ 不安全，新應用開發(fā)時就別用了，舊應用應該采取遷移行動”。
• 2024 年 7 月，美國網(wǎng)絡安全部門（CISA）聯(lián)合美國聯(lián)邦調(diào)查局（FBI）、澳大利亞信號局（ASD）、澳大利亞網(wǎng)絡安全中心（ACSC）和加拿大網(wǎng)絡安全中心（CCCS）共五大機構(gòu)發(fā)布了一份 22 頁的調(diào)查報告——《探索關鍵開源項目中的內(nèi)存安全》，發(fā)現(xiàn) 172 個項目中有 52% 是使用 C、C++ 和其他所謂“內(nèi)存不安全”的語言編寫的，希望引發(fā)眾人的重視。

在連番呼吁之下，內(nèi)存安全問題確實引起了一定的重視。為此，一些組織也開始了行動，如：

• 互聯(lián)網(wǎng)安全研究小組的 Prossimo 項目與 weedegolf 合作，用 Rust 重寫 Network Time Protocol (NTP) ，以提供內(nèi)存安全的 NTP。
• 早些時候，蘋果公司修改了用于構(gòu)建 iBoot 引導載入程序的 C 編譯器工具鏈，以減少內(nèi)存和類型安全問題。
• 有消息稱，微軟已經(jīng)用 3.6 萬行 Rust 代碼改寫了 Windows 內(nèi)核；
• 2022 年 12 月，Linux 內(nèi)核 6.1 發(fā)布，包含了初始 Rust 支持...

然而，擺在現(xiàn)實中的問題是，即使當代開發(fā)者深諳要在編寫程序的時候盡可能地使用內(nèi)存安全的語言，也做了如上所述的一些嘗試，但要知道 C 語言誕生于 20 世紀 70 年代，發(fā)展至今已經(jīng)五十多年的歷史，早已變得無處不在，無論是現(xiàn)代智能手機，還是太空飛行器等各種應用程序，都有它的身影。

就連 DARPA 也坦言，美國國防部的長壽命系統(tǒng)對 C 語言等編程語言的依賴程度更高。

手動地一行一行改寫代碼，亦或者正確遵守 ISO 標準并認真應用測試工具就可以避免安全漏洞，顯然有些不太現(xiàn)實。

DARPA 也得出了一個結(jié)論：經(jīng)過二十多年對 C 和 C++ 內(nèi)存安全問題的努力，軟件工程社區(qū)已達成共識，僅僅依靠錯誤查找工具是不夠的。

遷移是巨大的問題

然而此前，美國政府機構(gòu)在發(fā)出呼吁的同時也指出，向 MSL（內(nèi)存安全語言）過渡將涉及重大投資和高管關注，此外任何此類過渡都需要多年的精心規(guī)劃。

因此，雖然內(nèi)存安全編程語言可以消除內(nèi)存安全漏洞已經(jīng)不是什么秘密，但面臨的挑戰(zhàn)一直是如何大規(guī)模重寫傳統(tǒng)代碼，以應對龐大的問題。要想棄用，不談遷移代碼帶來的技術難度問題，僅是外在的人力、財力、精力成本都大到難以想象。

時下，始于大型語言模型 (LLM) 等機器學習技術的最新突破，DARPA 表示這創(chuàng)造了一種新解決方案的環(huán)境，即“通過大規(guī)模自動化，將世界上高度脆弱的遺留 C 代碼自動轉(zhuǎn)換成本質(zhì)上更安全的 Rust 編程語言。”

“你可以訪問任何 LLM 網(wǎng)站，開始與其中一個 AI 聊天機器人聊天，你只需要說‘這是一些 C 代碼，請將其轉(zhuǎn)換成安全的 Rust 代碼’，然后剪切、粘貼，就會出現(xiàn)一些結(jié)果，而且通常效果很好。”DARPA TRACTOR 項目經(jīng)理 Dan Wallach 博士說。

不過，這是理想狀態(tài)下的情況，Dan Wallach 表示，“但現(xiàn)實并非總是如此，研究挑戰(zhàn)在于大幅改進從 C 到 Rust 的自動轉(zhuǎn)換，特別是對于最相關的程序結(jié)構(gòu)。”

TRACTOR 的目標不僅是實現(xiàn)代碼轉(zhuǎn)換的自動化，而且要實現(xiàn)熟練開發(fā)人員手動編寫 Rust 代碼的高質(zhì)量和風格。

通過這樣做，該計劃旨在消除 C 程序中固有的內(nèi)存安全漏洞。除了利用軟件分析方法（包括靜態(tài)和動態(tài)分析）外，TRACTOR 還將采用 LLM 支持的解決方案并舉辦公開競賽來展示和測試這些創(chuàng)新。

Wallach 表示，“Rust 迫使程序員把事情做好，處理它強制執(zhí)行的所有規(guī)則可能會讓人感到束縛，但當你適應它們時，這些規(guī)則會給你自由。它們就像護欄；一旦你意識到它們是用來保護你的，你就會自由地專注于更重要的事情。”

當前，DARPA 已經(jīng)公開發(fā)布了這一計劃，也希望有更多的參賽者參與進來提交關于 LLM 支持的解決方案。DARPA 將于 2024 年 8 月 26 日舉辦一場活動，針對計劃為 TRACTOR 項目提交提案的人。這個活動可以親自參加，也可以遠程參加。不過，想要參加這個活動的人必須在 8 月 19 日之前進行注冊（https://sam.gov/opp/1e45d648886b4e9ca91890285af77eb7/view）。

AI 能一鍵實現(xiàn) C、C++ 代碼轉(zhuǎn)換成 Rust 代碼嗎？

從內(nèi)存安全出發(fā)，借助 AI 大模型的潛力，實現(xiàn)不同的語言代碼一鍵轉(zhuǎn)換，確實是一個不錯的想法。

據(jù)外媒 The Register 報道，Prossimo 項目執(zhí)行董事 Josh Aas 對此認為，“當今互聯(lián)網(wǎng)基礎設施中運行的大量 C 代碼使得使用翻譯工具變得很有吸引力。我們已經(jīng)對此進行了嘗試，例如我們最近將基于 C 語言的 AV1 實現(xiàn)轉(zhuǎn)換為 Rust。雖然目前的工具還需要不少手動調(diào)整才能讓結(jié)果正確并符合慣用法，但我們相信，通過進一步投資，這些工具將會變得更加高效。”

理想情況下，只要用自然語言告訴 AI 將 C、C++ 遺留代碼轉(zhuǎn)為 Rust 代碼，它確實會幫助轉(zhuǎn)換，但是這樣生成的結(jié)果是否可以直接使用？我們距離 TRACTOR 項目成為現(xiàn)實又還有多遠？

正在負責 TRACTOR 項目的工作 Wallach 坦言，該項目的目標是實現(xiàn)高度自動化，但這需要克服一些棘手的技術挑戰(zhàn)。

“其中一個挑戰(zhàn)是，當你讓大型語言模型（LLMs）轉(zhuǎn)換代碼時，它們有時能給出出乎意料的好答案，但也可能會產(chǎn)生錯誤的答案。另一個挑戰(zhàn)是 C 語言允許代碼對指針進行操作，包括算術運算，而 Rust 禁止這些操作。要彌合這一差距，不僅僅是把 C 語言直接轉(zhuǎn)換成 Rust 這么簡單。”

對于這一計劃，開發(fā)者的看法不一。

網(wǎng)友 mike_heran 認為：

• 這聽起來......很難。尤其是編寫 Rust 與 C 語言的習慣完全不同，而且大多數(shù)有趣的代碼都是用 C++ 編寫的。
  這不就等同于我們需要在靜態(tài)分析中確定所有 C 程序中內(nèi)存分配的生命周期，包括使用自定義分配器實現(xiàn)的分配，或者與專有庫交互的分配？多年來，盡管人們對這個問題進行了大量研究，但并沒有取得顯著成果。C/C++ 程序可以做一些事情，比如將內(nèi)存分配的生命周期與用戶點擊的按鈕關聯(lián)，而不是使用引用計數(shù)或其他機制來確保安全。雖然這不是一個好的做法，但它們確實可以這么做。
  編寫這種靜態(tài)分析工具的另一個顯著問題是，你所分析的程序本身可能是有漏洞的，生命周期分析可能沒有意義（如果生命周期明確，就不會有內(nèi)存安全漏洞，也就不需要替換）。我見過的關于靜態(tài)檢測生命周期問題的唯一研究，假定被分析的代碼從一開始就是正確的。不過，你可以嘗試開發(fā)一種程序，它能夠檢測出無法計算生命周期的地方，并向開發(fā)人員尋求幫助。

另一位開發(fā)者 blonk 表示：

「我個人并不認為這個項目有什么問題。問題更多在于“代碼庫有多大”以及“這真的是資源的最佳利用方式嗎？”我敢打賭，他們之所以想使用 LLM，是因為他們要移植的代碼量很大，所以他們想把這個過程自動化。如果是代碼庫龐大，那么我不確定使用 LLM 來加快進程是否是個好主意。

但這只是我的猜測。也有可能是這些項目歷史上存在大量內(nèi)存安全問題，而 Rust 可以捕捉到這些問題，在這種情況下，使用 LLM（有可能）是值得的。不管怎樣，我相信幾年后我們會知道更多關于這個項目是成功還是災難的信息。」

還有用戶 Rich 2 提出質(zhì)疑：

“如果你能開發(fā)出將 C 代碼轉(zhuǎn)換為 Rust 的工具，那么倘若 C 代碼確實包含內(nèi)存錯誤，將會發(fā)生兩種情況之一：

(a)工具會將這些錯誤一并轉(zhuǎn)換到 Rust 中，但因為 Rust 的語言特性，理論上不應該發(fā)生這種情況，因為 Rust 不支持導致這些錯誤的結(jié)構(gòu)。

(b) 工具會在轉(zhuǎn)換過程中發(fā)現(xiàn)并報告這些錯誤。

如果是(a)，即工具只會復制錯誤，那轉(zhuǎn)換并沒有任何意義；如果是(b)，即工具會發(fā)現(xiàn)并報告錯誤，那么為什么不直接修復 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/

— 完 —

如喜歡本文，請點擊右上角，把文章分享到朋友圈

1、2T架構(gòu)師學習資料干貨分享

2、10000+TB 資源，阿里云盤，牛逼！！

3、基本涵蓋了Spring所有核心知識點總結(jié)

  · END ·

最后，關注公眾號互聯(lián)網(wǎng)架構(gòu)師，在后臺回復：2T，可以獲取我整理的 Java 系列面試題和答案，非常齊全。

如果這篇文章對您有所幫助，或者有所啟發(fā)的話，幫忙掃描上方二維碼關注一下，您的支持是我堅持寫作最大的動力。

求一鍵三連點贊、轉(zhuǎn)發(fā)、在看