RFC-0251：無根存取

摘要

這份 RFC 詳細說明如何建立微調資源，而非存取根資源，以及這麼做的原因。最終目標是徹底根除根資源。由於資源使用範圍廣泛，我們必須徹底瞭解如何有效移除資源，同時不中斷目前依附於該資源的任何部分。

提振精神

根層級資源是一項強大的能力，可存取硬體資源，並在系統中公開大量高權限存取權。根資源可存取其組成資源。過去，由於只有核心、主機板驅動程式庫或指定的裝置驅動程式，才能指定更專業資源的有效範圍，因此很難將根資源拆分成其組成部分。雖然這種模式很方便，但為了存取專用資源，透過 component-manager 將根資源傳遞至元件，並不符合最低權限原則。我們只應傳送元件所需的資源，並完全移除根資源。

利害關係人

講師：leannogasawara@google.com

審查者：

• 安全性 (pesk@google.com)
• 驅動程式架構 (surajmalhotra@google.com)
• 元件架構 (geb@google.com)
• Zircon (maniscalco@google.com)
• 車手 (cja@google.com)

需求條件

在應公開微調資源的地方，卻使用根資源。大多數通話網站已更新，可存取專門資源。如果目前無法這麼做，就必須定義、路由及公開新資源，確保系統遵守最低權限原則。

設計

component-manager 可為每個資源代管服務，並個別路由傳送每種資源。許多資源已實作這項功能，但正式來說，這應該是處理所有資源種類的設計，而不是利用根資源存取專門資源。

實作

在仍使用根資源的位置，我們應找出程序所需的特定資源，並建立權限較少的更精細資源。新的資源會改為傳送至元件，而非傳送至根資源。應存在的細部資源清單如下：

• cpu 資源：取得及設定 CPU 效能參數
• 偵錯資源：用於存取各種核心偵錯系統呼叫
• 能源資訊資源：存取能源消耗資訊
• debuglog 資源：啟用讀取及寫入偵錯記錄
• 訊框緩衝區資源：取得及設定啟動載入器訊框緩衝區
• 管理程序資源：建立可在管理程序中執行的虛擬機器
• 資訊資源：用於核心統計資料
• iommu 資源：由 iommu 管理工具使用
• ioport 資源：閘道存取 x86 ioport
• irq 資源：閘道存取中斷物件
• mexec 資源：用於啟動系統
• mmio 資源：閘道存取 mmio
• msi 資源：用於在 PCI 上分配 MSI 範圍
• 電源資源：操控 CPU 電源
• 設定檔資源：用於建立排程器設定檔
• smc 資源：平台裝置通訊協定用來存取 SMC 範圍
• vmex 資源：將 VMO 標示為可執行

這些新資源會取代目前依附於根資源的系統呼叫，確保每個呼叫都取得正常運作所需的最小權限。

針對每個新發現的資源：

• 如果資源對應至範圍資源，則應有自己的定義類型，且沒有基底。這包括 ioport、irq、mmio 和 smc 資源。
• 對於所有其他資源，資源種類會是系統資源，並採用新定義的基礎類型。
• 現有的核心系統呼叫會更新，除了根資源外，還會接受及驗證更精細的資源。
• 元件管理員需要導入新服務，才能提供新資源的控制代碼。
• 呼叫網站和對應的 CML 檔案會更新，以使用更精細的資源。

當所有需要存取根資源的呼叫都已替換為更專業的資源，即可從 driver-manager 和 component-manager 中移除 fuchsia.boot.RootResource 服務。可從政策檔案中移除其曝光度，這樣一來，日後程式設計師嘗試使用該資源時，就必須先通過安全性審查，才能完全根除。

在這個階段，根資源只會由核心建立，並做為系統的第一個程序傳遞至使用者空間。可以變更核心，停止建立資源，並更新其系統呼叫，只針對更精細的資源進行驗證。根資源將不再存在。

component_manager 中代管的新服務應如下所示：

@discoverable
closed protocol IommuResource {
    strict Get() -> (resource struct {
        resource zx.Handle:RESOURCE; }
    );
};

效能

預計不會有變化。

安全性考量

這項 RFC 可縮小根資源的表面積，並相應地將高權限存取權限縮至僅限核心，進而提升系統安全性。最初公開根資源是為了方便作業。使用者空間不應存取根資源，尤其是在有直接實作方式可使用更精細的資源時。下游有更多資源需要維護，但元件應負責瞭解所需的特定資源，而不是使用功能強大的根資源。

隱私權注意事項

這項 RFC 不會影響隱私權。

測試

component-manager 中已存在組成資源的測試。新資源可以複製這個範例，確保資源能正常運作。從 CML 移除 fuchsia.boot.RootResource 通訊協定的路由時，如果仍有對根資源的呼叫，CICQ 就會中斷。通過 CICQ 測試後，應該就足以確認新資源可正常運作，且不再需要根資源。

說明文件

建立新資源時，也需要更新 resource documentation。許多測試都會參照名為 root_resource 的虛假資源。變數名稱也應更新，以參照更具體的資源 (如適用)。

缺點、替代方案和未知事項

替代做法：不採取任何行動

這項 RFC 的替代方案是讓問題維持現狀。系統會照常運作，且維護資源較少。然而，現狀違反了「程式只會存取所需資源」的承諾。使用者空間中的任何項目都不需要存取根資源。根資源是功能強大的資源，可執行的作業遠超出必要範圍。經過微調的資源路徑可讓貢獻者更輕鬆地確保元件只具備必要的最低權限。

另一種替代做法是使用根工作。所有其他作業都會從這個程序衍生，就像根資源可以建立所有其他資源一樣。您可以將根資源替換為根工作，但這無法解決減少存取權的問題，也無法提供更精細的存取權解決方案。

後續作業

從今天起，根資源不再由元件或驅動程式庫程式架構提供服務，也不在核心測試中。政策檔案未提供這項功能。核心仍在建立，並在資源檢查中驗證。 移除驗證是根資源的最後一個清除步驟。