RFC-0251：無根存取

摘要

這份 RFC 詳細說明如何建立精細調整的資源，以及為何要建立精細調整的資源，而非存取根資源。最終目標是完全根除根源資源。由於這項資源廣泛使用，我們必須徹底瞭解如何有效移除這項資源，同時不會破壞目前依賴這項資源的眾多部分。

提振精神

根層級資源是一項強大的能力，可讓您存取硬體資源，並在系統中提供大量的高度特權存取權。根資源可存取其構成資源。以往，要將根資源拆分為其構成元素，一直是一件困難的事，因為只有核心、板卡驅動程式庫或指定裝置驅動程式，才有能力為更專門的資源指定有效範圍。雖然這種透過 component-manager 將根資源傳遞至元件，以便存取專用資源的模式相當方便，但並未遵循最低權限原則。我們應該只傳送元件所需的資源，並完全移除根資源。

相關人員

講師：leannogasawara@google.com

審查者：

• 安全性 (pesk@google.com)
• Driver Framework (surajmalhotra@google.com)
• 元件架構 (geb@google.com)
• Zircon (maniscalco@google.com)
• 車手 (cja@google.com)

需求條件

在應公開更精細資源的地方使用根資源。大部分的呼叫網站都已更新，可存取專屬資源。在目前無法這樣做的情況下，必須定義、路由及公開新的資源，讓系統遵循最低權限原則。

設計

component-manager 可為每項資源代管服務，並個別轉送每種資源。這項功能已為許多資源實作，但正式的設計應是處理所有資源類型，而非使用根資源存取專用資源。

實作

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

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

這些新資源將取代目前依賴根資源的系統呼叫，讓每個呼叫都能取得最小許可權，以便正常運作。

針對每個新識別的資源：

• 如果資源對應於範圍資源，則應具有其自身定義的類別，而沒有 base。包括 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 的替代做法是讓問題持續存在。系統會正常運作，且需要維護的資源較少。不過，現況違反了「程式只能存取所需資源」的承諾。使用者空間中沒有任何項目需要存取根資源。根資源是一項強大的能力，可執行超出必要範圍的作業。經過精細調整的資源轉送功能，可讓開發人員更輕鬆地確保其元件僅能存取必要的最低權限。

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

未來工作

自今日起，元件或驅動程式庫程式架構不再提供根資源，核心測試也不再提供根資源。並未透過政策檔案提供。它仍由核心建立，並在資源檢查中驗證。移除驗證是根資源移除作業的最後一步。