| RFC-0118：映像汇编时的 SWD 政策 | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | 在映像组装时应用 SWD 政策的短期变更。 |
| 问题 | |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2021-06-28 |
| 审核日期（年-月-日） | 2021-07-28 |
总结
此 RFC 提出了一种权宜之计，即通过定义易于理解的作用域政策来实现软件交付 (SWD) 政策配置的可见性和可伸缩性，以便任何开发者都能了解哪些软件可以在运行 Fuchsia 的设备上运行，哪些软件不可以在运行 Fuchsia 的设备上运行，并确保他们不会意外交付安全性较低的配置。
当前方案旨在以当前形式存在，直到基于子组件的产品组件允许针对不同产品用例更明确定义的政策。此方案中的中间工作可以更轻松地过渡到系统组装式配置，因为集中处理 SWD 政策的工作已经完成。
设计初衷
SWD 配置对于强制执行已验证执行至关重要。目前，SWD 配置拆分为多个配置文件和软件包，这些配置文件和软件包会相互交互，以确定设备上的实际 SWD 配置。此 RFC 旨在降低理解产品 SWD 状态的复杂性。通过添加易于理解和深思熟虑的政策，还可以更简单、更安全地添加新产品和变体，从而减轻确保应用正确配置的负担。
设计
此 RFC 中目前提出了三项 SWD 政策。此类库旨在通过语义（而非产品驱动）命名来正式化 SWD 政策配置。
必要时，我们可能会添加更多政策，但这组政策预计会远远少于产品和 build 变体的增长幅度。
政策定义
仅限基础组件
所有可执行代码都必须直接验证（基于基础）。所有可配置 SWD 限制都会设置为其默认安全状态：不允许对代码库进行动态配置，并且可执行性限制处于启用状态，这意味着只有基本组件和列入许可名单的组件才能解析和执行。
本地动态配置
当且仅当用户有物理访问权限（例如开发者）时，才允许动态配置代码库和手动解析间接验证的代码（通用软件包/临时组件）。
无限制
对代码的可执行性或可见性没有任何限制。这是允许外部代码和动态配置的最大宽松 SWD 配置，并且还停用了可执行性限制。
政策表
| POLICY_NAME | enable_dynamic_configuration | persisted_repos_dir | disable_executability_restrictions |
|---|---|---|---|
| base_components_only | OFF | OFF | OFF |
| local_dynamic_config | ON | OFF | OFF |
| 无限制 | ON | ON | ON |
实现
此 RFC 提议在映像组建级别实现这一点。由于 SWD 配置要求同时在 base_packages 和 system_image_deps 中设置值，因此我们提议修改相应的组目标，以添加对基于 policy_labels build 参数定义的 GN 组的新依赖项。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 配置状态的简易性、可伸缩性和易用性，而 SWD 配置状态决定了哪些软件可以在 Fuchsia 设备上运行。这样，开发者在推出配置不安全的产品时不太可能会直接改善我们的安全状况。减少的配置空间也让产品所有者更轻松地进行审核。
隐私注意事项
此变更不会影响隐私，也不会与用户数据互动。
测试
系统将测试此更改，以确保此更改后的 build 具有预期的 SWD 政策配置。具体方法是，在变更前后手动验证输出 build 是否具有预期文件（对于 disable_executability_restrictions）和 config-data 软件包（对于 enable_dynamic_configuration 和 persisted_repos_dir）。
文档
我们将添加其他文档来定义 SWD 政策配置。
缺点、替代方案和未知情况
此更改只是一种短期解决方案，在平台子组件存在之前，我们可以通过它对构建流程进行更精细的控制。这项工作已在进行中的子组件 RFCS (fxr/553664) 和结构化配置 (fxr/549661) 中捕获。
需要注意的是，这项变更会将软件包/依赖项包含从产品定义中抽象出来。
已调查的替代方案包括：
未进行任何更改
我们可以继续在当前环境中生活，在该环境中，每个产品都可以修改自己的配置，并且每个产品都会继续随机地从其祖先实体的并集继承。
但是，随着 Fuchsia 产品系列快速增长，我们提出了这一方案，旨在主动改进 SWD 配置机制，以防范可能将错误 SWD 状态应用于产品的事件，打破 Fuchsia 平台的核心安全假设。
修改产品定义
这与目前的做法类似，但不同的是，我们不会在产品定义的继承树中随意定义各种设置，而是在每个级别定义设置。我们确定这是不可行的，因为这不仅需要了解每个旋钮对开发者的作用，而且无法扩展到不断增长的产品中。这还带来了额外的负面影响，即对树的根/祖先级别所做的任何更改都必须更改所有子级别，以取消或重置关联的组件。
在构建验证时断言
我们可以分担确定 build 是否使用正确配置进行构建验证这一问题，并断言每个 build 都关联了正确的依赖项。这解决了确保构建的图像具有正确配置的问题，既不能解决可听性/可见性问题，也不能改善理解 SWD 堆栈在给定配置中的行为的工效学设计。
修改/减少 SWD 配置设置集
我们调查了能否通过修改 SWD 逻辑来减少更改至单个值的设置数量。遗憾的是，这被认为不可行，因为 SWD 堆栈是在多个软件包和 zbi 中的多个组件中实现，其配置分布在所有软件包和 zbi 中。