投資消毒殺菌劑

  • 專案主管：phosek@google.com、shayba@google.com
  • 區域：工具鍊

問題陳述

記憶體安全錯誤一直是影響安全性的高嚴重性錯誤根本原因。此外，出現消毒液器也可以快速呈現及根除棘手錯誤，藉此提升工程工作效率。儘管 Fauchsia 在這個網域中具有相對優勢，例如不同軟體之間有更完善的隔離機制，以及持續投資可安全記憶體安全系統程式設計語言等，由於 Fuchsia 會在其他平台上運作，記憶體安全仍保持重要。

目前 Fuchsia 使用數種消毒液偵測記憶體安全錯誤：

  • AddressSanitizer (ASan) 會偵測超出存取範圍的執行個體、在釋放 / 傳回 / 範圍後使用，且會重複釋放。相對地，kasan 會將其延伸至核心程式碼。
  • LeakSanitizer (LSan) 可偵測記憶體流失情形。
  • UndefinedBehaviorSanitizer (UBSan) 會偵測依賴未定義的程式行為的特定問題。
  • 此外，Fusia 支援 libFuzzer，可執行涵蓋率導向的模糊測試，並偵測上述清理器可偵測到的當機或問題。目前正在努力提高核心系統呼叫模糊化作業的涵蓋率。
  • 最後， Fuchsia 支援 GWP-ASan，這是 Asan 取樣版本。我們正在著手示範在實際工作環境中的用途，用來偵測實地中的錯誤。

這些清理程式涵蓋 C/C++ 程式碼，但無法保證記憶體的安全性。也會偵測 Rust 不安全的區塊中的記憶體錯誤，並找出 Rust 程式碼中的記憶體流失情形。

這些工具經證實能有效找出錯誤。未偵測到錯誤時，開發人員無須採取任何行動。偵測到錯誤時，由於消毒器會提供堆疊追蹤，方便您輕鬆分析及找出可重現的行為，因此疑難排解相對簡單。

在 2020 至 2021 年期間，努力廣泛推出全部三種消毒劑，並修正既有錯誤。這些工作仰賴先前的專屬工作，在 Fuchsia 上支援執行階段檢測支援。他們隨後由志工和 20%的人員暫時派遣，到現在已經結束。

不過，我們仍在持續改善。特別是：

  • 某些與硬體相關的程式碼不在清理工具的涵蓋範圍內，主要是因為執行階段效能問題和自動化缺口。
  • 針對使用者空間程式碼，核心程式碼的 Sanitizer 落後。
  • 還有其他類別可執行消毒工具，但在 Fuchsia 尚未支援，特別是針對未初始化的讀取，以及各種執行緒安全錯誤。
  • 在特定測試的邊界之外，系統內偵測到的消毒液不會自動導致這類錯誤，您必須手動分類，才能將其指派給擁有者。

在 Fuchsia 團隊當時，我們尤其會關注裝置驅動程式庫程式開發和樹狀結構外開發投入更多資源，以及兩者合併投入的心力。其他問題也持續缺乏資料品質，導致工程的工作效率降低。

解決方案陳述

我們投入更多資源來提供清理工具，並進一步開發 LLVM 編譯器執行階段檢測支援等方面。具體違規事項如下：

支援更消毒液，例如：

修正現有消毒液的長期問題，例如：

探究商機並呈現未來工作藍圖，例如：

  • 以追蹤 Fuchsia 優先順序的方式，在更多設定 (除了 qemu 以外) 上啟用消毒液。
  • 找出檢測中未實際執行的程式碼 (例如驅動程式和其他硬體相關程式碼)，然後依照優先順序來消除這些落差。
  • 評估及量化消毒液對 Fuchsia 的影響，包括發現問題的規模和分佈情形、嚴重程度、從偵測到維修所需時間、技術債庫存和製定量化計畫。
  • 研究新的商機，例如針對已在其他平台看到採用的消化器硬體支援，或是執行其他最佳化作業，例如檢測版本中的內嵌作業。
  • 請考慮增加針對 Rust 的消毒工具投資，例如檢查記憶體安全問題時克服 FFI 邊界，或加入與 Rust 同等的 UBSan。

依附元件

  • Sanitizer 的啟動工作仰賴 Fuchsia Toolchain 團隊提供的 LLVM 專業知識，且應擴展至更多人員，以改善團隊健康狀態。
  • 硬體加速功能 (例如頂部位元組忽略 (TBI)) 需要所有傳遞指標的 sys 呼叫來支援核心。
  • EngProd 團隊需要進行研究室裝置佈建和變更，才能建構和測試自動化容量和設定，才能在硬體上執行消毒液。
  • Sanitizer 變化版本和各種切換鈕需要由 Fuchsia Build 團隊提供支援。

請注意，上述所有團隊都致力於確保消毒液正在運作，並定期進行會議。

風險與緩解措施

  • 部分工作 (尤其是啟動) 可能需要幾年才能呈現及驗證。這需要長期承諾和全心投入工作，並須耐心等待。
  • 對硬體檢測的可行性有一些期望是推測，假設會追蹤其他平台上的先進技術，並適用於特定且未公開的目標硬體選擇。