RFC-0118：图片组装时的 SWD 政策

摘要

此 RFC 提出了一个权宜解决方案，通过定义众所周知且受限的政策，让软件交付 (SWD) 政策配置的公开范围、易懂性和可伸缩性得到更好的提升，以便任何开发者都能了解哪些软件可以在搭载 Fuchsia 的设备上运行，哪些软件不能运行，并确保他们不会意外发布安全性较低的配置。

在基于子组件的商品组装支持为不同商品用例定义更明确的政策之前，当前提案将保持现有形式。由于集中应用 SWD 政策的工作已经完成，因此此提案中的中间工作将有助于更轻松地过渡到系统汇编式配置。

设计初衷

SWD 配置对于强制执行经过验证的执行至关重要。目前，SWD 配置分布在多个配置文件和软件包中，这些配置文件和软件包相互交互以确定设备上的实际 SWD 配置。此 RFC 旨在降低了解产品 SWD 状态的复杂性。添加深刻理解且经过深思熟虑的政策还有助于更轻松、更安全地添加新产品和变体，从而减轻确保应用正确配置的负担。

设计

目前，此 RFC 中提出了三项 SWD 政策。它们旨在通过基于语义（而非产品）的命名来规范 SWD 政策配置。这些政策将应用于商品定义，以更全面的方式定义 SWD 状态，并且

我们可能会根据需要添加更多政策，但这组政策的数量预计仍远远少于产品和 build 变体的增长速度。

政策定义

仅限基本组件

所有可执行代码都必须直接进行验证（在 base 中）。所有可配置的 SWD 限制都设置为默认的安全状态：不允许动态配置代码库，并且可执行性限制处于开启状态，这意味着只有基本组件和许可名单中的组件是可解析和可执行的。

本地动态配置

仅当用户具有实际访问权限（例如开发者）时，才允许动态配置代码库和手动解析间接验证的代码（通用软件包/短时性组件）。

无限制

对代码的可执行性或可见性没有任何限制。这是最宽松的 SWD 配置，允许外部代码和动态配置，还会停用可执行性限制。

政策表

实现

此 RFC 建议在映像汇编级实现此功能。由于 SWD 配置需要在 base_packages 和 system_image_deps 中设置值，因此建议修改相应的组目标，以添加对基于 policy_labels build 参数定义的 GN 组的新依赖项。该字典存储一组由映像汇编理解的键值对（在本例中为 swd）及其各自的政策标签。

这样，我们就可以确保为给定 build 始终定义一个 SWD 政策配置。

例如，假设政策在 //build/security/policies_swd.gni 中定义：

policies_swd = [
  {
    name = "local_dynamic_config"
    base_package_deps = [ /* ... */ ]
    system_image_deps = [ /* ... */ ]
    bootfs_deps = [ /* ... */ ]
  },
  {
    name = "foo"
    // ...
  },
]

在产品定义文件中，产品所有者可以执行以下操作：

import("//build/images/policy.gni")  # defines policy_labels = {} arg.
policy_labels.swd = "local_dynamic_config"
policy_labels.foo = "bar"

在映像组装步骤中：

group("base_packages") {
  testonly = base_cache_packages_testonly
  visibility = [ ":*" ]
  public_deps = [
    // ...
  ]
  // Addition for this proposal
  deps = []
  foreach (policy, policies_swd) {
    if (policy.name == policy_labels.swd) {
      deps += policy.base_package_deps
    }
  }
}

请注意，这并不能完全解决从祖先 GNI 文件继承产品定义的问题。不过，它简化了 SWD 政策的配置和可审核性。

性能

这项更改不会影响效果。

工效学设计

此更改通过提取配置设置（以便 SWD 配置由单个 build 参数控制），简化了对设备上 SWD 状态的理解和审核。

向后兼容性

此更改不会影响向后兼容性，更改的结构应易于还原。

安全注意事项

这项变更提高了 SWD 配置状态的简单性、可伸缩性和可读性，该状态决定了哪些软件可以在 Fuchsia 设备上运行。这样一来，开发者就更不太可能发布配置不安全的产品，从而直接改善我们的安全状况。缩减配置空间后，产品所有者也更容易进行审核。

隐私注意事项

此项更改不会影响隐私权或与用户数据互动。

测试

我们将对此更改进行测试，以确保此更改后的 build 具有预期的 SWD 政策配置。为此，您需要在更改前后手动验证输出 build 是否包含（或不包含）预期文件（对于 disable_executability_restrictions）和配置数据软件包（对于 enable_dynamic_configuration 和 persisted_repos_dir）。

文档

我们将添加其他文档来定义 SWD 政策配置。

缺点、替代方案和未知情况

在平台子组件出现之前，此更改旨在作为短期解决方案，以便我们更精细地控制构建流程。这项工作已记录在子组件 (fxr/553664) 和结构化配置 (fxr/549661) 的进行中 RFC 中。

此项更改的主要注意事项是，它会将软件包/依赖项包含从产品定义中抽象出来。

调查的替代方案包括：

不进行任何更改

我们可以继续在当前环境中工作，在这种环境中，每个产品都可以修改自己的配置，并且每个产品都会继续从其祖先的联合中随意继承。

不过，随着 Fuchsia 产品的快速增长，我们提出了此提案，以便主动改进 SWD 配置机制，以防将错误的 SWD 状态应用于产品，从而破坏 Fuchsia 平台的核心安全假设。

修改产品定义

这与目前的做法类似，但我们会在每个级别定义设置，而不是在产品定义的继承树中随意定义各种设置。我们认定这种做法不可行，因为它会让开发者承担了解每个旋钮功能的责任，并且无法扩展到不断增加的产品组合。这还会带来额外的弊端，即对树的根/祖先级别所做的任何更改都必须更改所有子级别，以取消设置或重置关联的组件。

在构建验证时进行断言

我们可以将确定 build 是否使用正确配置的问题转移到 build 验证，并断言正确的依赖项与每个 build 相关联。这解决了确保构建的映像具有正确配置的问题，但并不能解决可听度/可见度问题，也不能改进在给定配置中了解 SWD 堆栈行为的人体工学。

修改/减少一组 SWD 配置设置

我们调查了是否可以修改 SWD 逻辑，以将要更改的设置数量减少到一个值。遗憾的是，这被认为是不可行的，因为 SWD 堆栈在多个软件包和 zbi 中的多个组件中实现，配置分布在所有这些组件中。