| RFC-0199：保護子項 VMAR | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 允許 zx_vmar_protect 適用於子項 VMAR 中的對應。 |
| 問題 | |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2022-09-13 |
| 審查日期 (年-月-日) | 2022-11-03 |
摘要
允許 zx_vmar_protect 減少範圍內子 VMAR 的權限。
提振精神
在 Fuchsia 上，軟體 (例如元件載入器) 將對應項放置在子 VMAR 中並不罕見，但不會保留並將控制代碼傳遞至這些子 VMAR。在這種情況下，即使使用名義上是範圍父項授權的根 VMAR，也無法再對這些對應執行 zx_vmar_protect 等作業。
protect 無法提升權限，超出用於建立對應的控制代碼所允許的範圍，通常用於在應用程式中提供額外的錯誤檢查。舉例來說，應用程式可能會移除對未使用堆積部分的存取權限，藉此偵測任何使用後釋放或存取權遭濫用的情況。
在某些情況下，不需要提升權限，protect 僅用於減少權限。在這些情況下，如果對應項目位於子項 VMAR 中，無法使用 protect 減少權限，應用程式可執行的錯誤偵測就會減少。
利害關係人
協助人員：
cpu@google.com
審查者：
travisg@google.com、rashaeqbal@google.com、nickcano@google.com
已諮詢：
wez@google.com、palmer@google.com、mvanotti@google.com
社交：
這項提案先前已與 Zircon 團隊討論過。
設計
導入新的權限 ZX_RIGHT_OP_CHILDREN，可控制物件上的作業是否允許遞迴至子物件。這項提案只會賦予 VMAR 這項權利，其他物件則不適用。右側會成為 ZX_DEFAULT_VMAR_RIGHTS 的一部分。
現有作業的定義將變更，以便透過下列方式瞭解這項權利：
zx_vmar_protect：可遞迴套用至子區域中的對應，但子區域對應只能降低權限。我們會在下一節中進一步討論。zx_vmar_unmap和zx_vmar_op_range：已遞迴，且會遵守限制這項權利的新規定。zx_vmar_destroy：邏輯上是遞迴，需要操作權限。
所有作業的 API 說明都會定義為：當指定範圍包含子區域，但不存在 ZX_RIGHT_OP_CHILDREN 權限時，會傳回 ZX_ERR_ACCESS_DENIED。
在處理範圍時，核心 VMAR 程式碼已可遞迴至子 VMAR，因此不需要為此設計新方法，因為可以使用現有的列舉工具。
保護
zx_vmar_protect 是唯一在 ZX_RIGHT_OP_CHILDREN 存在時獲得功能的作業，本節將探討權限對應的運作方式，以及這項作業套用至子項對應時的適用情形。protect
對應權限
對應有兩種權限概念。
- 用來建立對應的 VMAR 和 VMO 控制代碼的存取權交集。這代表對應項目的最高權限。
- 系統會根據對應項目的目前作業權限，檢查所有存取權。這些權限一律會等於或少於最高權限。
首次建構時，系統只會從控制代碼權限推斷最大權限，使用者無法限制這項權限。初始作業權限是在 zx_vmar_map 的選項中設定，且必須小於或等於控制代碼的最大權限。
建構完成後，您隨時可以使用 zx_vmar_protect 作業變更作業權限，但要求權限不得超過原始最大權限。
因此，即使對應項目的最大權限允許讀取，如果目前的權限不允許讀取，系統仍會拒絕存取並產生例外狀況。其他 VMAR 作業 (例如 zx_vmar_op_range) 的運作方式與 protect 類似，都是以最高權限 (而非目前權限) 為閘道。
階層權限
與對應不同，VMAR 只有單一權限概念，且無法變更。使用 zx_vmar_allocate 建立 VMAR，並將下列項目做為輸入內容：
- 父項 VMAR 的控制代碼
- 新 VMAR 的權限
如預期，這裡要求的權限必須等於或少於父項 VMAR 控制代碼的權限。
產生的子 VMAR 控制代碼會將控制代碼權限設為與建立的 VMAR 權限相符，也就是與要求的權限相符。
這會造成兩項後果：
- 在 VMAR 階層中，權限只能減少，不能增加。
- VMAR 控制代碼的控制代碼權利絕不會超過 VMAR 權限，但權限可能會減少。
影響
目前 zx_vmar_protect 作業對要求的權限設有三項限制：
- 叫用的 VMAR 控制代碼必須具備所要求的權限。
- 最內層 VMAR 涵蓋範圍所叫用的 VMAR，不會遞迴至子 VMAR。
- 範圍內的每個對應都必須具備足夠的最高權限。
這項異動將第二項規定改為：範圍內子 VMAR 中的每個對應項，都必須具有等於或大於所要求權限的目前作業權限。
實作
這項功能可以透過幾個小型 CL 完整實作：
- 將
ZX_RIGHT_OP_CHILDREN導入核心 API。 - 為每個 VMAR 作業新增支援，更新說明文件，並視需要新增測試。
效能
預計不會影響成效。變更實作項目以支援子 VMAR 疊代，可能會導致現有案例效能不佳，而 Zircon 微基準會用於檢查這點。
回溯相容性
ZX_RIGHT_OP_CHILDREN 將是預設權限，而對於已遞迴的現有作業，行為將維持不變。protect 預設會具備遞迴功能，但使用者不應在測試以外的情況下，依賴系統產生這類錯誤。因此，protect 成功而非失敗，不應中斷任何現有使用者。
安全性考量
目前，我們是透過將對應項放置在 VMAR 中、保護該對應項，然後捨棄 VMAR 的控制代碼，來建立無法變更權限的對應項。即使對應具有較大的最大權限，由於沒有 VMAR 控制代碼，目前的權限永遠無法變更。如果可以增加這些對應的權限，就會違反安全性屬性。
雖然這項提案允許變更子 VMAR 中的權限，但只能減少權限，不能增加。以類似的例子來說，您已經可以使用 zx_vmar_unmap 作業，將子區域的權限有效縮減為零。如果可以選擇性地將權限減少到介於無權限和目前權限之間的某個值，並不會提供任何額外的權限類型。
注重安全性的元件也可以從擁有的任何控制代碼中移除 ZX_RIGHT_OP_CHILDREN。
缺點、替代方案和未知事項
傳遞所有 VMAR 控制代碼
主要替代方案是維持核心不變，並變更使用者空間，以追蹤及傳遞所有子 VMAR 控制代碼。雖然概念簡單，但由於這項資訊交換必須在元件建立界線發生，因此定義或擴充 API 來轉移這項資訊，會是相當重要的變更。
除了這種做法的實作複雜度較高之外，一般而言，為了執行作業而需要保留及追蹤所有子項 VMAR 或 VMO 控制代碼，對使用者空間來說是不合理的負擔，這點已獲得普遍認同。