RFC-0253：zx_object_get_info ZX_INFO_VMAR_MAPS

問題陳述

如果呼叫端只關心一個 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 是否通過的影響？(這個部分為選填，但建議填寫)。

協助人員：

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

社交化：在草擬這份 RFC 前，我們曾與 adamperry@ 和 adanis@ 簡短討論這項提案。

需求條件

本提案的目的是允許 Starnix 查詢特定 VMAR (Linux 程序位址空間，又稱受限區域)，而非整個程序的位址空間，藉此提升 Starnix 效能。

效率：新的系統呼叫應執行與指定 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 不同，結果的深度欄位會與指定的 VMAR 相關，而非指定的程序。第一個結果記錄的深度為 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 的呼叫端應會發現效能有所提升，這是因為系統呼叫執行的工作減少，且任何呼叫後篩選步驟都已排除。

人體工學

為方便使用，結果類型和語意會與現有呼叫 (object_get_info，搭配 ZX_INFO_PROCESS_MAPS) 密切相符。

回溯相容性

建議的變更可回溯相容。現有通話不受影響。 新通話的行為與現有通話類似。

安全性考量

因為傳回的資訊是 ZX_INFO_PROCESS_MAPS 傳回資訊的子集，且新的 object_get_info 呼叫會需要現有 ZX_INFO_PROCESS_MAPS 呼叫所需的相同控制代碼權限，因此安全性範圍或狀態不會有任何變更。

隱私權注意事項

沒有隱私權疑慮。

測試

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

說明文件

系統呼叫文件將更新，說明新的呼叫。

缺點、替代方案和未知事項

實作這項提案只需要少量工程資源。新系統呼叫的後續維護作業應盡量減少。此外，新呼叫不會大幅降低 (核心實作) 彈性或 (API) 自由度。

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

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

根據這項提案，系統會回報每個造訪節點的深度欄位，該欄位與目標 (指定的 VMAR) 相關，且從零開始。

另一種做法是回報相對於程序位址空間的深度。 也就是回報絕對深度。這兩個選項都符合規定，且達成目標的成效相近。

我們選擇了相對於目標的深度，因為這樣可向呼叫者揭露較少資訊，且在內部鎖定策略方面，可提供更多實作彈性。

既有技術和參考資料

另請參閱 ZX_INFO_PROCESS_MAPS 和 ZX_INFO_VMAR。