| RFC-0118：映像汇编时的 SWD 政策 | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | 在映像组装时应用 SWD 政策的短期更改。 |
| 问题 | |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2021-06-28 |
| 审核日期（年-月-日） | 2021-07-28 |
摘要
此 RFC 提出了一个权宜解决方案，通过定义众所周知且受限的政策，让软件交付 (SWD) 政策配置的公开范围、易懂性和可伸缩性得到更好的提升，以便任何开发者都能了解哪些软件可以在搭载 Fuchsia 的设备上运行，哪些软件不能运行，并确保他们不会意外发布安全性较低的配置。
在基于子组件的商品组装能够针对不同的商品使用情形制定更明确的政策之前，当前提案将保持现有形式。此方案中的中间工作将有助于更轻松地过渡到系统组装式配置，因为集中应用 SWD 政策的工作已经完成。
设计初衷
SWD 配置对于强制执行经过验证的执行至关重要。目前，SWD 配置分布在多个配置文件和软件包中，这些配置文件和软件包相互交互以确定设备上的实际 SWD 配置。此 RFC 旨在降低了解产品 SWD 状态的复杂性。添加经过深思熟虑且易于理解的政策还有助于简化和确保更安全地添加新产品和变体，从而减轻确保应用正确配置的负担。
设计
目前，此 RFC 中建议了三项 SWD 政策。它们旨在通过基于语义（而非产品）的命名来规范 SWD 政策配置。这些政策将应用于商品定义，以更全面的方式定义 SWD 状态，并且
我们可能会根据需要添加更多政策，但这组政策的数量预计仍远远少于产品和 build 变体的增长速度。
政策定义
仅基本组件
所有可执行代码都必须直接进行（基于基础）验证。所有可配置的 SWD 限制都会设置为其默认安全状态：不允许对代码库进行动态配置，并且已启用可执行性限制，这意味着只有基础组件和列入许可名单的组件可解析和执行。
本地动态配置
当且仅当用户（例如开发者）具有实际访问权限时，才允许动态配置代码库和手动解析间接验证的代码（通用软件包/临时组件）。
无限制
对代码的可执行性或可见性没有任何限制。这是最宽松的 SWD 配置，允许外部代码和动态配置，还会停用可执行性限制。
政策表
| POLICY_NAME | enable_dynamic_configuration | persisted_repos_dir | disable_executability_restrictions |
|---|---|---|---|
| base_components_only | 关闭 | 关闭 | 关闭 |
| local_dynamic_config | 已启用 | 关闭 | 关闭 |
| 无限制 | 已启用 | 已启用 | 已启用 |
实现
此 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 中的多个组件中实现的，配置分布在所有这些组件中。