O(x)Caml 在太空：以記憶體安全保護最後的疆域

將軟體部署到低地球軌道（LEO）會面臨一系列獨特的挑戰：極端環境、有限的連線以及失敗的高昂代價。當錯誤進入軌道後，無法僅僅透過 SSH 連線到伺服器並重新啟動程序；核心修補變成一個複雜的交付問題，而整個系統崩潰可能意味著數百萬美元資產的損失。

最近，代號 Borealis 的專案——CCSDS 協定堆疊的純 OCaml 實作——成功在 DPhi Space 的 ClusterGate-2 有效載荷模組內啟動。此部署證明，高階且具記憶體安全性的語言不僅適用於太空應用，更是確保下一代載荷衛星安全的關鍵。

Borealis 的架構

Borealis 作為守護程式運作，管理地面站與衛星之間的通訊。雖然它提供標準的用戶端-伺服器介面以處理遙測與指令，但其底層傳輸是 CCSDS（太空資料系統諮詢委員會）協定族的純 OCaml 實作。

延遲容忍網路

由於衛星無法持續連線，Borealis 將檔案系統視為延遲容忍網路。每個指令、回應與遙測樣本皆序列化為 BPv7（Bundle Protocol 第 7 版）捆綁檔，寫入磁碟。DPhi 的 API 會在下一次可用的通過期間轉送這些不透明位元組。

安全封裝

在共享硬體上作為租戶執行時，安全性至關重要。Borealis 使用 BPSec 將每個捆綁檔包裹在加密與驗證區塊中。這確保即使主機的 Linux 核心被入侵——考慮到像「Dirty Frag」或「Copy Fail」等核心層級 CVE 的普遍性，這是一個真實威脅——路由路徑仍然位於信任路徑之外。衛星營運者只能看到不透明的位元組，無法讀取、修改或偽造內容。

後量子就緒性

展望長期任務（10–15 年），Borealis 採用 ML-DSA-65 為後量子簽章金鑰實作空中重新鑰匙（OTAR）。這是 NASA 太空系統保護標準（NASA-STD-1006A）的關鍵需求。透過實作 OTAR，Parsimoni 能在不重新寫入衛星的情況下輪換金鑰，成為首批公開的軌道上後量子 OTAR 示範之一。

效能與 OxCaml 優勢

雖然 OCaml 5 提供安全的多執行緒與高效能，但衛星調度的「熱路徑」——每個封包都必須解碼與路由——需要極低的抖動。這正是 OxCaml，Jane Street 的實驗性編譯器分支，發揮變革性作用的地方。

消除 GC 抖動

在標準 OCaml 中，每個封包的配置通常會落到堆上，觸發小規模的垃圾回收（GC）循環。在高吞吐量環境下，這些循環會產生延遲峰值（抖動），可能破壞嚴格的排程期限。

透過使用 OxCaml 的模式系統與 exclave_ stack_ 註解，開發者可以將配置標記為堆疊綁定。這確保它們永不進入堆，也不會觸發 GC。結果相當顯著：

  • p99.9 延遲: 從每封包 29 ns 降至 9 ns。
  • GC 壓力: 在 2500 萬封包中，從 394 次小 GC 降至零次。

正如社群成員所指出的，這讓開發者在預設情況下仍能享受 GC 語言的易用性，僅在效能關鍵的地方選擇類似手動記憶體控制的方式。

為何選擇 OCaml 用於太空？

歷史上，太空軟體主要由 C 與 C++ 主導，但這些語言承載著大量記憶體腐敗的漏洞。Microsoft 與 Chromium 的研究顯示，約 70% 的嚴重 CVE 源於記憶體安全問題。在太空領域，這可從 NASA CryptoLib TC 框架解析器中發現的堆緩衝區溢位等錯誤看出。

OCaml 從根本上消除整個攻擊面。為了進一步確保正確性，Borealis 採用多層防禦：

  1. 正式驗證: 使用 libcrux 與 fiat-crypto 進行密碼學原語的驗證。
  2. 型別化綱要: 以型別化綱要產生線路格式編解碼器，並透過 Microsoft 的 EverParse 進行驗證。
  3. 型別驅動的狀態機: 協定狀態以 GADT 編碼，使編譯器在編譯時即可拒絕無效的轉換。

前進之路：擴大艦隊規模

Borealis 不僅僅是一個在軌道上的單一二進位檔；它是構建太空軟體新方式的概念驗證。此專案利用 MirageOS 的函式庫，證明十年前用於雲端 unikernel 的相同工具組，同樣適用於衛星載荷的管線建置。

下一個挑戰是規模化。隨著硬體變得常規化，焦點轉向軟體堆疊：以與 Docker 管理地面 Linux 容器相同的便利性，管理大量專用載荷二進位檔。這需要建立安全、簽名的更新路徑，以及在單一衛星總線上多租戶之間的強韌隔離。

透過結合 ML 的數學嚴謹性與 OxCaml 的效能優化，Parsimoni 正示範「最後的疆域」既安全又高效。

Sources