| RFC-0251：无 root 访问权限 | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | 访问经过微调的资源，而不是根资源 |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2023-11-20 |
| 审核日期（年-月-日） | 2024-06-05 |
摘要
此 RFC 详细说明了创建微调资源的方法和原因， 访问根资源。最终目标是彻底根除根源 资源。由于其使用非常普遍，因此我们需要彻底了解如何 高效利用资源，同时又不会破坏 都依赖于它。
设计初衷
根资源是一项强大的功能，可用于访问硬件
并公开大范围访问具有高特权的跨区域资源，
系统。根资源允许访问其组成资源。
过去，我们很难将根资源拆分为
因为只有内核、板级驱动程序或指定的设备驱动程序才会
能够为更专业的资源指定有效范围。
通过
component-manager 以及组件，以便访问专用资源
未遵循最小权限原则。我们只应将
移除组件所需的资源，并完全移除根资源。
利益相关方
教员：leannogasawara@google.com
审核者：
- 安全 (pesk@google.com)
- 驱动程序框架 (surajmalhotra@google.com)
- 组件框架 (geb@google.com)
- Zircon (maniscalco@google.com)
- 驱动程序 (cja@google.com)
要求
根资源正用于需要更精细的资源的位置 改为公开。大多数调用点已更新为 专用资源在目前还无法做到这一点的地方， 必须是定义、路由和公开的新资源，以便系统坚持 最小权限原则
设计
component-manager 可以按资源托管服务，并路由每个资源
种类。许多资源都已采用这种做法，但正式
设计用于处理所有资源类型，而不是利用
根资源来访问专用资源。
实现
在根资源仍在使用的位置，我们应确定 进程所需的特定资源，并创建更精细的资源 权限较低。新资源将路由到 来代替路由根资源的位置更精细的资源列表 应为：
- cpu 资源：获取和设置 CPU 性能参数
- 调试资源：用于访问各种内核调试系统调用
- 能耗信息资源：访问能耗信息
- 调试日志资源：允许读取和写入调试日志
- 帧缓冲区资源：获取和设置引导加载程序帧缓冲区
- Hypervisor 资源：创建可在 Hypervisor
- 信息资源：用于内核统计信息
- iommu 资源：由 iommu 管理器使用
- ioport 资源：对 x86 ioport 的门控访问权限
- irq 资源：控制对中断对象的访问
- mexec 资源：用于启动系统
- mmio 资源：对 mmio 的门控访问权限
- msi 资源：用于在 PCI 上分配 MSI 范围
- 电源资源：操纵 CPU 功耗
- profile 资源：用于创建调度器配置文件
- smc 资源：供平台设备协议用于访问 SMC 范围
- vmex 资源：将 VMO 标记为可执行文件
这些新资源将取代当前依赖于根目录的系统调用 以便每个调用都能获得正常运行所需的最小权限， 。
对于确定的每项新资源：
- 如果该资源对应于一个范围资源，则它应该有自己的 定义的种类，无基数。这包括 ioport、irq、mmio 和 smc 资源。
- 对于所有其他资源，资源种类将是具有 新定义的基本类型。
- 现有的内核系统调用将进行更新，以接受和验证更精细的 以及根资源以外的精细资源
- 组件管理器将需要引入新服务来提供句柄 新资源
- 调用网站和相应的 cml 文件会进行更新，以便使用更精细的 资源。
当需要访问根资源的所有调用都已替换为
fuchsia.boot.RootResource 服务可以
已从“driver-manager”和“component-manager”中删除。可能会消除其暴露风险
从政策文件获取，这样即使以后编程人员也需要进行安全审核，
在资源被彻底清除之前，尝试使用该资源。
在此阶段，根资源只会由内核创建并传递 作为系统的第一个进程进入用户空间。内核可以更改 停止创建资源，并更新其系统调用以仅验证 更精细的资源根资源将不再存在。
在 component_manager 中托管的新服务应如下所示：
@discoverable
closed protocol IommuResource {
strict Get() -> (resource struct {
resource zx.Handle:RESOURCE; }
);
};
性能
预计不会发生任何变化。
安全注意事项
此 RFC 通过减小 及其拥有的高特权访问权限，只能访问 内核版本。根资源最初是公开的，因为这样做很方便 用户空间应该无权访问根资源，尤其是存在 提供了如何使用更细粒度资源的直接实现。 下游需要维护更多资源，但组件应 负责了解所需的特定资源，而不是使用 非常强大的根资源
隐私注意事项
此 RFC 不会影响隐私权。
测试
中已有的组成资源进行了测试
component-manager。新资源可以复制此示例，以确保它们
按预期运行。移除 fuchsia.boot.RootResource 协议的路由时
从 cml 中加载，如果仍然调用根资源，则 CICQ 会中断。答
通过 CICQ 测试应该就足以测试新资源是否正常运行，
不再需要根资源。
文档
创建新资源后，需要将 resource documentation
也进行了更新许多测试都会引用名为
root_resource。此外，还应更新变量名称，以引用更多
特定资源（如适用）。
缺点、替代方案和未知问题
替代方案：不执行任何操作
这个 RFC 的替代方案是让熟睡的狗狗撒谎。系统的运作方式 而且需要维护的资源也更少。然而，目前的现状是违反 并承诺程序只能访问所需的资源。 用户空间中的任何内容均不需要访问根资源。根资源是 实现远超所需的用途的强大功能。经过进一步微调 通过资源路由，贡献者可以更轻松地确保自己的 组件只能访问 必填字段。
另一种方法是使用根作业。继承的所有其他作业 其过程与根资源创建所有其他资源的方式非常相似。 可以用根作业替换根资源，但无法解决 或者它没有引入更精细的解决方案， 访问权限。
未来工作
即日起，该组件不再提供根资源 驱动程序框架，也不在核心测试中。并非通过政策提供 文件。它仍在由内核创建并在资源检查中进行验证。 移除验证是根除根资源的最后一步。