RFC-0253：zx_object_get_info ZX_INFO_VMAR_MAPS

RFC-0253：zx_object_get_info ZX_INFO_VMAR_MAPS
狀態已接受
領域
  • 核心
說明

這個 RFC 建議新增一個 zx_object_get_info 主題，ZX_INFO_VMAR_MAPS。
問題
蓋爾特變化
  • 1068292
作者
審查人員
提交日期 (年-月-日)2024-07-19
審查日期 (年-月-日)2024-07-17

編輯此 RFC

編輯 RFC 中繼資料

問題說明

如果呼叫端只重視單一 VMAR，則 ZX_INFO_PROCESS_MAPS 的效率不佳。

ZX_INFO_PROCESS_MAPS 會疊代處理程序的位址空間，並提供呼叫端 使用 zx_info_maps_t 結構體來描述每個位址區域和對應 可用來執行程序如果來電者只想要一部分資訊， 例如：只有單一 VMAR 的內容，仍必須支付全額費用。 更糟的是，呼叫端必須接著篩選搜尋結果。

摘要

我們提議新增 object_info 主題 ZX_INFO_VMAR_MAPS， 跟 ZX_INFO_PROCESS_MAPS 有關，不過以 VMAR 來說

相關人員

誰會負責確認 RFC 是否已獲接受？(這個部分為選填，但 encouraged.)

講師：

審查人員：adamperry@ (Starnix)、adanis@ (Zircon VM)、dworsham@ (Zircon VM)、 mcgrathr@ (Zircon)

社交：已針對 adamperry@ 和 adanis@ 進行簡短討論 草擬此 RFC。

需求條件

本提案的目的是為了提升 Starnix 成效， 查詢特定 VMAR (Linux 程序位址空間，亦即受限制的位址空間) 區域)，不必輸入整個程序的位址空間。

效率 - 新系統呼叫的執行作業應與 指定的 VMAR 大小/複雜程度

邏輯與人體工學 - 新呼叫應會產生以下結果： 結構類似現有 ZX_INFO_PROCESS_MAPS 中 ，盡量減少對想要使用新呼叫的現有呼叫端作業。

設計

我們會新增一個名為 ZX_INFO_VMAR_MAPS 的 object_info 主題。這個新主題 運作方式與現有 ZX_INFO_PROCESS_MAPS 類似，但不會傳回 就會傳回指定程序的結果 VMAR.

和 ZX_INFO_PROCESS_MAPS 一樣，最終價格會是深度優先的預購 也能週遊

第一筆結果記錄會說明指定的 VMAR。

與 ZX_INFO_PROCESS_MAPS 不同，結果的深度欄位會是相對的 而非指定的程序第一個屬性的深度 結果記錄將會是 0。

為了方便說明，object_get_info 的新版文件將顯示如下：

If *topic* is `ZX_INFO_VMAR_MAPS`, *handle* must be of type `ZX_OBJ_TYPE_VMAR`
and have `ZX_RIGHT_INSPECT`.

和

### ZX_INFO_VMAR_MAPS

*handle* type: `VM Address Region`, with `ZX_RIGHT_INSPECT`

*buffer* type: `zx_info_maps_t[n]`

The `zx_info_maps_t` array is a depth-first pre-order walk of the target
VMAR tree. As per the pre-order traversal base addresses will be in ascending
order.

See `ZX_INFO_PROCESS_MAPS` for a description of `zx_info_maps_t`.

The first `zx_info_maps_t` will describe the queried VMAR. The *depth*
field of each entry describes its relationship to the nodes that come
before it. The queried VMAR will have depth 0. All other entries have
depth 1 or greater.

Additional errors:

*   `ZX_ERR_ACCESS_DENIED`: If the appropriate rights are missing.
*   `ZX_ERR_BAD_STATE`: If the target process containing the VMAR has
    terminated, or if the address space containing the VMAR has been
    destroyed.

實作

新功能將會導入一系列可回溯相容的小型版本 更新 (包括測試與說明文件更新) 的內容部分現有程式碼 將重構，讓 ZX_INFO_PROCESS_MAPS 和 ZX_INFO_VMAR_MAPS。

成效

不會影響現有的程式碼/系統。完成後，會遷移的呼叫端 ZX_INFO_PROCESS_MAPS到 ZX_INFO_VMAR_MAPS應該就會有成效 相較於 syscall 帶來的減少工作 淘汰任何通話後篩選器步驟。

人體工學

為方便起見，結果類型和語意將密切符合 現有通話：object_get_info，撥號對象：ZX_INFO_PROCESS_MAPS。

回溯相容性

提議的變更可以回溯相容。現有通話不會受到影響。 新呼叫的運作方式與現有呼叫類似。

安全性考量

因為傳回的資訊是所傳回內容的子集 ZX_INFO_PROCESS_MAPS，而且新的 object_get_info 呼叫需要 與現有 ZX_INFO_PROCESS_MAPS 呼叫所需的帳號代碼相同， 安全表面區域和型態將維持不變

隱私權注意事項

無隱私權疑慮。

測試

核心測試套件將更新，以測試新呼叫。

說明文件

更新 Syscall 文件會更新說明新的呼叫。

缺點、替代方案和未知

導入此提案只需要投入少量心力， 對新 syscall 進行後續維護的時間應降到最低。此外， 呼叫不會大幅降低 (核心實作) 彈性或 (API) 自由選擇。

實作新主題的主要替代方案是繼續使用 並繼續篩選結果。ZX_INFO_PROCESS_MAPS

相對於目標與位址空間的深度

在本提案下方，每個造訪節點回報的深度欄位都是相對的 並將初始值設為 0 的指定 VMAR

另一種方法是回報相對於程序位址空間的深度。 換句話說，系統會回報絕對的深度。這兩種方式都符合 成效表現出跟既定目標差不多

我們選擇的深度與目標相對，因為這會對 方便開發人員在設計時更有彈性 內部鎖定策略

既有藝術品和參考資料

另請參閱 ZX_INFO_PROCESS_MAPS 和 ZX_INFO_VMAR。