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

摘要

本文档详细介绍了如何以及为什么要创建经过微调的资源，而不是访问根资源。最终目标是彻底根除根资源。由于其广泛使用，我们需要彻底了解如何有效地移除该资源，同时又不会破坏目前依赖于它的众多部分。

设计初衷

根资源是一项强大的功能，可访问硬件资源，并在系统中公开大量具有高特权的访问途径。根资源允许访问其组成资源。从历史上看，很难将根资源拆分为其组成部分，因为只有内核、板级驱动程序或指定的设备驱动程序才有知识来为更专用资源指定有效范围。虽然这种通过 component-manager 将根资源传递给组件以访问专用资源的模式很方便，但并不遵循最小权限原则。我们应仅发送组件所需的资源，并彻底移除根资源。

利益相关方

教练：leannogasawara@google.com

Reviewers:

• 安全团队 (pesk@google.com)
• 驱动程序框架 (surajmalhotra@google.com)
• 组件框架 (geb@google.com)
• Zircon (maniscalco@google.com)
• 驱动程序 (cja@google.com)

要求

在应公开更精细的资源的位置使用根资源。大多数呼叫网站都已更新，可访问专用资源。在目前无法做到这一点的地方，必须定义、路由和公开新的资源，以便系统遵循最小权限原则。

设计

component-manager 可以按资源托管一个服务，并单独路由每种资源。这已针对许多资源实现，但从严格意义上讲，应将其作为处理所有资源类型的设计，而不是使用根资源来访问专用资源。

实现

在仍在使用根资源的位置，我们应确定进程所需的特定资源，并创建权限更低的精细资源。系统会将新资源路由到组件，而不是路由根资源。应存在的精细资源列表如下：

• CPU 资源：获取和设置 CPU 性能参数
• 调试资源：用于访问各种内核调试系统调用
• 能耗信息资源：访问能耗信息
• debuglog 资源：启用对调试日志的读写
• 帧缓冲区资源：获取和设置引导加载程序帧缓冲区
• Hypervisor 资源：创建可在 Hypervisor 中运行的虚拟机
• info 资源：用于内核统计信息
• 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 的替代方案是“勿以恶小而为之”。系统会按原样运行，并且需要维护的资源更少。不过，现状违背了“程序只能访问其所需资源”的承诺。用户空间中的任何内容都不需要访问根资源。根资源是一项强大的功能，可执行超出必要范围的操作。通过更精细的资源路由，贡献者可以更轻松地确保其组件只能访问所需的最少权限。

另一种替代方案是使用根作业。所有其他作业都派生自此进程，就像根资源可以创建所有其他资源一样。可以将根资源替换为根作业，但这并不能解决减少访问权限的问题，也无法引入更精细访问权限的解决方案。

后续工作

从今天起，组件或驱动程序框架不再提供根资源，核心测试中也不再包含根资源。它不会通过政策文件提供。它仍由内核创建，并在资源检查中进行验证。移除验证是根资源根除的最后一步。