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。
问题
Gerrit 更改
作者
审核人
提交日期（年-月-日）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 不同，结果的深度字段是相对的 发送到指定的 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应该都会有效果 系统调用和 Google Cloud 的 省去了任何调用后过滤步骤。

工效学设计

为了便于使用，结果类型和语义将与 现有通话，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。