| 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、rasheqbal@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 完全實作，這些 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 句柄，對使用者空間來說也是不合理的負擔。