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 效能參數
• 偵錯資源：用於存取各種核心偵錯 syscalls
• 能源資訊資源：存取能源消耗資訊
• 偵錯記錄資源：啟用讀取和寫入偵錯記錄
• framebuffer 資源：取得和設定系統啟動載入程式 framebuffer
• 管理程序資源：建立可在 管理程序
• 資訊資源：用於核心統計資料
• iommu 資源：iommu Manager 使用的資源
• ioport 資源：x86 ioport 的存取門
• irq 資源：限制干擾物件的存取權
• 用於啟動系統的 Mexec 資源
• mmio resource：mmio 出入口
• MSI 資源：用來在 PCI 上分配 MSI 範圍
• 耗電量：控管 CPU 效能
• 設定檔資源：用來建立排程器設定檔
• smc 資源：平台裝置通訊協定會使用這個資源來存取 SMC 範圍
• vmex 資源：將 VMO 標示為執行檔

這些新資源會取代目前依附於根的系統呼叫 確保每次呼叫都能取得運作所需的最低權限 而非偏誤。

針對每個識別的新資源：

• 如果資源對應到範圍資源，則該資源應有專屬的 定義種類，也沒有基底包括 ioport、irq、mmio 和 smc 再複習一下，機構節點 是所有 Google Cloud Platform 資源的根節點
• 所有其他資源則會是系統資源 新定義的基礎類型
• 將更新現有核心系統呼叫，以接受並驗證更精細的 除了根資源外，也能選擇精細的資源
• 元件管理員需要推出新服務來提供帳號代碼 並介紹新資源
• 呼叫站台和對應的 Cml 檔案會更新以使用更精細 再複習一下，機構節點 是所有 Google Cloud Platform 資源的根節點

如果所有需要存取根資源的呼叫已替換為 fuchsia.boot.RootResource 服務則可 已從「driver-manager」和「component-manager」中移除。皮膚暴露在風險中可能會 ，因此程式設計師日後必須接受安全性審查 嘗試在資源恢復正常前先行使用

在這個階段，根資源只會由核心建立並傳遞 設為使用者空間您可以變更核心 即可停止建立資源並更新系統呼叫 精細的資源根資源已不存在。

「Component_manager」中代管的新服務應如下所示：

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

成效

預期不會有任何變化。

安全性考量

此 RFC 透過降低 完全無法存取 核心。根資源剛公開，因為有足夠時間 例如使用者空間不應無法存取根資源 它具備直接實作，說明如何使用更精細的資源。 下游還有更多需要維護的資源，但元件應該 瞭解他們需要的特定資源，而不是使用 強大的根資源

隱私權注意事項

此 RFC 不會影響隱私。

測試

現有的成員資源已對 component-manager。新資源可複製這個範例，確保 正常運作，移除 fuchsia.boot.RootResource 通訊協定的路徑時 從 cml 載入，如果仍有對根資源的呼叫，CICQ 就會損毀。A 罩杯 通過 CICQ 應足以測試新資源是否正常運作， 表示不再需要根資源

說明文件

建立新資源時，resource documentation 必須 。許多測試都會參照直接呼叫的假資源 root_resource。您也應該更新變數名稱，以參照更多 以及適用的特定資源

缺點、替代方案和未知

替代做法：不執行任何動作

這個 RFC 的另一個替代方案是讓睡中的狗散步。系統運作方式 減少需要維護的資源然而，現狀違反了 保證程式只能存取所需的資源。 使用者空間中沒有任何項目需要存取根資源。根資源是 能力更為強大進一步微調 資源轉送功能可讓貢獻者輕鬆確保 元件只提供最低限度的權限 這通常代表交易 不會十分要求關聯語意

另一個替代方案是使用根工作。所有其他工作都是衍生自 這就如同根資源可建立所有其他資源的方式一樣。 可將根資源替換為根工作，但也不能解決 也能降低存取機率 資源存取權

未來工作

即日起，元件或 以及核心測試並非透過政策提供 檔案。核心仍在建立執行個體，且資源檢查作業也會驗證相同的設定。 移除驗證是釋放根資源的最後一個步驟。