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 的替代方案是让熟睡的狗狗撒谎。系统的运作方式 而且需要维护的资源也更少。然而,目前的现状是违反 并承诺程序只能访问所需的资源。 用户空间中的任何内容均不需要访问根资源。根资源是 实现远超所需的用途的强大功能。经过进一步微调 通过资源路由,贡献者可以更轻松地确保自己的 组件只能访问 必填字段。
另一种方法是使用根作业。继承的所有其他作业 其过程与根资源创建所有其他资源的方式非常相似。 可以用根作业替换根资源,但无法解决 或者它没有引入更精细的解决方案, 访问权限。
未来工作
即日起,该组件不再提供根资源 驱动程序框架,也不在核心测试中。并非通过政策提供 文件。它仍在由内核创建并在资源检查中进行验证。 移除验证是根除根资源的最后一步。