| RFC-0251：沒有根存取權 | |
|---|---|
| 狀態 | 已接受 |
| 領域 |
|
| 說明 | 存取經過微調的資源取代根資源 |
| 毛皮變化 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2023-11-20 |
| 審查日期 (年-月-日) | 2024-06-05 |
摘要
這份 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 的另一個替代方案是讓睡中的狗散步。系統運作方式 減少需要維護的資源然而，現狀違反了 保證程式只能存取所需的資源。 使用者空間中沒有任何項目需要存取根資源。根資源是 能力更為強大進一步微調 資源轉送功能可讓貢獻者輕鬆確保 元件只提供最低限度的權限 這通常代表交易 不會十分要求關聯語意
另一個替代方案是使用根工作。所有其他工作都是衍生自 這就如同根資源可建立所有其他資源的方式一樣。 可將根資源替換為根工作，但也不能解決 也能降低存取機率 資源存取權
未來工作
即日起，元件或 以及核心測試並非透過政策提供 檔案。核心仍在建立執行個體，且資源檢查作業也會驗證相同的設定。 移除驗證是釋放根資源的最後一個步驟。