| RFC-0199：保護子項 VMAR | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 允許 zx_vmar_protect 套用至子項 VMAR 中的對應。 |
| 問題 | |
| 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年/月) | 2022-09-13 |
| 審查日期 (年/月) | 2022-11-03 |
摘要
允許 zx_vmar_protect 減少範圍內子項 VMAR 的權限。
提振精神
在 Fuchsia 中，軟體 (例如元件載入器) 會將對應放置在子 VMAR 中，但無法保留控點並傳遞至這些子 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、paler@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 只有一個權限概念，且無法變更。VMAR 是以 zx_vmar_allocate 建立，並接收輸入內容：
- 由父項 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 控點以執行作業，而會對使用者空間造成不合理的負擔。