RFC-0251：无根目录访问权限

摘要

此 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 性能参数
• 调试资源：用于访问各种内核调试系统调用
• 能耗信息资源：访问能耗信息
• debuglog 资源：允许读取和写入调试日志
• 帧缓冲区资源：获取和设置引导加载程序帧缓冲区
• hypervisor 资源：创建可在 hypervisor 中运行的虚拟机
• 信息资源：用于内核统计信息
• iommu 资源：由 iommu 管理器使用
• ioport 资源：对 x86 ioport 的门控访问
• irq 资源：门控对中断对象的访问
• mexec 资源：用于启动系统
• mmio 资源：门控对 mmio 的访问
• msi 资源：用于在 PCI 上分配 MSI 范围
• 电源资源：操控 CPU 电源
• 配置文件资源：用于创建调度器配置文件
• smc 资源：由平台设备协议用于访问 SMC 范围
• vmex 资源：将 VMO 标记为可执行

这些新资源将取代目前依赖于根资源的系统调用，以便每个调用获得正常运行所需的最低权限。

对于识别出的每项新资源：

• 如果资源对应于范围型资源，则应具有自己定义的种类，而没有基础。这包括 ioport、irq、mmio 和 smc 资源。
• 对于所有其他资源，资源种类将是具有新定义的基本类型的系统资源。
• 现有内核系统调用将更新为除了接受和验证根资源之外，还接受和验证更精细的资源。
• 组件管理器需要引入新服务来提供新资源的句柄。
• 调用方和相应的 CML 文件会更新为使用更精细的资源。

当需要访问根资源的所有调用都替换为更专业的资源后，可以从 driver-manager 和 component-manager 中移除 fuchsia.boot.RootResource 服务。可以从政策文件中移除其公开性，以便在未来的程序员尝试使用该资源之前，需要进行安全审核，直到该资源完全被清除。

在此阶段，根资源将仅由内核创建，并作为系统的第一个进程传递给用户空间。可以更改内核，以停止创建资源并更新其系统调用，使其仅针对更精细的资源进行验证。根资源将不再存在。

在 component_manager 中托管的新服务应如下所示：

@discoverable
closed protocol IommuResource {
    strict Get() -> (resource struct {
        resource zx.Handle:RESOURCE; }
    );
};

性能

预计不会发生变化。

安全注意事项

此 RFC 通过将根资源的表面积（以及相应的高度特权访问权限）减小到仅限内核，从而提高了系统的安全性。最初公开根资源是因为这样做很方便。用户空间不应有权访问根资源，尤其是在存在有关如何使用更精细资源的直接实现时。下游有更多资源需要维护，但组件应负责了解它们所需的特定资源，而不是使用非常强大的根资源。

隐私注意事项

此 RFC 不会影响隐私权。

测试

component-manager 中已存在的组成资源有对应的测试。新资源可以复制此示例，以确保它们按预期工作。从 CML 中移除 fuchsia.boot.RootResource 协议的路由时，如果仍有对根资源的调用，CICQ 将中断。通过 CICQ 测试应足以测试新资源是否正常运行，以及是否不再需要根资源。

文档

创建新资源后，还需要更新 resource documentation。许多测试都引用了一个名为 root_resource 的假资源。变量名称也应更新为引用更具体的资源（如适用）。

缺点、替代方案和未知因素

替代方案：不执行任何操作

此 RFC 的替代方案是让问题保持原样。系统按原样运行，需要维护的资源更少。然而，现状违反了程序只能访问所需资源的承诺。用户空间中的任何内容都不需要访问根资源。根资源是一项强大的功能，可以执行比必要操作更多的操作。更精细的资源路由可让贡献者更轻松地确保其组件只能访问所需的最少权限。

另一种替代方法是使用根作业。所有其他作业都源自此进程，这与根资源可以创建所有其他资源非常相似。虽然可以将根资源替换为根作业，但这并不能解决减少访问权限的问题，也无法提供更精细的访问权限解决方案。

未来工作

截至目前，根资源不再由组件或驱动程序框架提供，也不再位于核心测试中。未通过政策文件提供。它仍由内核创建，并在资源检查中进行验证。移除验证是根资源根除的最后一步。