Linux 核心導入 Rust，表面上是用記憶體安全語言降低漏洞；但在 Linux 7.3 開發週期，一行 Kconfig 變更卻讓既有的 RandStruct 結構布局隨機化不再於特定測試環境預設啟用。這不是「Rust 取代安全防護」的簡單故事，而是核心團隊在執行期防禦、建置覆蓋率與跨語言相容性之間做出的暫時取捨。
先釐清事件：不是 Linux 7.3-rc1 已經關閉
來源事實：Linux 官方檔案站顯示，7.3-rc1 於 2026 年 8 月 30 日發布；RandStruct 變更則由 Linus Torvalds 在 9 月 2 日合併，提交訊息明確標為供 7.3-rc2 使用的 hardening 修正。因此，精確說法應是「進入 Linux 7.3 開發樹、預計自 rc2 起出現」，而不是 rc1 本身已帶有這項修改。官方合併紀錄只有一行新增、一行刪除：https://github.com/torvalds/linux/commit/940de590b839f71d6dc846160534bf202401b8b7；版本狀態可見 https://cdn.kernel.org/。
原始報導掌握了核心衝突，但把影響概括成「有 Rust 就預設關閉 RandStruct」，仍需補上條件與時序：https://www.webpronews.com/linux-kernels-rust-push-forces-trade-off-on-core-security-feature/。
RandStruct 防的是什麼
來源事實：RandStruct 會在編譯時重排特定 C 結構的成員，包括全部由函式指標構成，或被明確標註為需要隨機化的結構。攻擊者即使取得可覆寫核心記憶體的漏洞，也較難直接套用已知欄位偏移；部分攻擊因而還需要先取得資訊洩漏，才能還原布局。
它不是消除漏洞，而是提高利用難度。其編譯種子必須保密，外部模組也要沿用同一種子；官方 Kconfig 同時提醒，完整隨機化可能增加記憶體與效能成本，並妨礙 Volatility 等鑑識工具。GCC 外掛與 Clang 對位元欄位的處理也不完全相同。這些限制均寫在目前的核心設定檔：https://github.com/torvalds/linux/blob/master/security/Kconfig.hardening。
真正衝突在 C／Rust 邊界與測試覆蓋
來源事實：核心 Rust 程式透過 bindgen 從 C 標頭產生型別與函式繫結，再由 Rust 抽象層包裝。官方文件強調，安全保證成立的前提，是抽象本身必須 sound，且所有 unsafe 程式碼遵守安全契約：https://cdn.kernel.org/doc/html/latest/rust/general-information.html。當 C 編譯器私下重排結構、Rust 端卻無法得到一致布局，兩邊便不能安全互通。
原本的相依條件會在 RandStruct 啟用時排除 Rust；問題是 allmodconfig 會盡可能把可模組化功能設成模組，用來廣泛編譯驅動程式與子系統。核心提交檢查表也要求補丁通過 allmodconfig，顯示它不是邊緣測試：https://docs.kernel.org/process/submit-checklist.html。RandStruct 先取得預設值，結果便是 Rust 程式碼離開這張常用測試網。
新條件只有在 COMPILE_TEST 成立、Rust 工具鏈可用且架構具 Rust 支援時，才不再把 RANDSTRUCT_FULL 設為預設。更微妙的是，它檢查的是「可用能力」，不是 CONFIG_RUST 本身；補丁作者 Mark Brown 因而承認，某些組態可能最後連 Rust 與 RandStruct 都沒開。這是繞過 Kconfig 循環相依的權宜設計，不是兩者已經相容。
為何現在值得注意
合理推論：維護者選擇保住 Rust 的 allmodconfig 覆蓋，代表 Rust 已不能再被當成「測不到也無妨」的實驗附件。郵件討論中，Rust 維護者 Miguel Ojeda 認為保留 linux-next 的 Rust 測試很重要，但也坦言失去另一側覆蓋「感覺不好」；討論紀錄見 https://lists.openwall.net/linux-hardening/2026/08/21/38。
作者觀點：這項交換並不是拿 Rust 的安全性等價替換 RandStruct。Rust主要降低新寫 Rust 程式碼產生部分記憶體安全錯誤的機率；RandStruct 則是在漏洞已存在、且攻擊者鎖定敏感 C 結構時增加利用障礙。前者偏向預防缺陷，後者偏向阻礙利用，保護層次不同。真正被拿來比較的，是「今天多一層執行期防禦」與「讓更多 Rust 程式碼每天被編譯、及早抓出退化」的工程價值。
實際影響沒有標題看來那麼全面
這次改的是預設選擇，不是刪除 RandStruct，也不是命令所有 Linux 發行版關閉它。主要發行版、雲端業者與設備商通常維護自己的正式核心組態，並不直接把 allmodconfig 當產品設定。因此，僅憑「升級到 7.3」不能斷言系統已失去防護；反過來，也不能只看到 Rust 工具鏈存在便假定 Rust 已啟用。
較直接受影響的是核心 CI、linux-next 測試者、產生新組態的客製核心團隊，以及依賴上游預設值的建置流程。既有產品若固定保存並審核 .config，結果可能完全不變；若每版重新生成設定，則應比較實際輸出的 CONFIG_RUST、CONFIG_RANDSTRUCT 與 CONFIG_RANDSTRUCT_FULL。
對台灣讀者的意義
合理推論：這對一般桌面使用者不是立即要切換選項的警報，卻與台灣的伺服器、NAS、路由器、工控設備及其他嵌入式產品開發團隊高度相關。這些產品常同時維護 BSP、外部驅動與客製安全設定；真正的風險不是上游改了一行，而是升版流程未保存組態差異、CI 只測單一組合，或外部模組拿不到相同的 RandStruct 種子。
採購與資安稽核也不宜只問「核心版本是否支援 Rust」，而應追問出貨映像實際啟用了哪些設定、Rust 與 C 驅動各自經過哪些測試，以及廠商是否保留其他核心強化措施。版本名稱不是安全保證，最終的二進位組態才是。
後續觀察指標
- Linux 7.3 後續 RC 與正式版是否保留目前條件，或再修正「兩者皆關閉」的邊角情境。
- 上游能否讓 bindgen、Clang 與 GCC 路徑取得一致的隨機化布局，使 Rust 與 RandStruct 真正共存。
- 主要發行版與設備商的實際
.config，而非上游預設值，是否出現變化。 - CI 是否分開保留「Rust 覆蓋」與「RandStruct 覆蓋」，避免解決一張測試網的缺口，卻讓另一張長期消失。
這一行修改的真正訊號，是 Linux 正進入 C 與 Rust 長期共存的過渡期。成熟防禦不會自然移植到新語言，新語言的安全承諾也不能自動保護所有舊 C 程式碼。能否把兩者重新疊加，而不是永久二選一，才是這場爭議最後應接受的檢驗。