RFC-0075：弃用了适用于配置设备的基于 Zedboot 的铺砌

RFC-0075：弃用了用于配置设备的基于 Zedboot 的铺垫功能
状态已接受
领域
  • 常规
说明

围绕 fastboot 实现设备配置标准化，并废弃基于 Zedboot 的 paving。
Gerrit 更改
作者
审核人
提交日期（年-月-日）2021-02-25
审核日期（年-月-日）2021-03-12

编辑此 RFC

修改 RFC 元数据

摘要

本文档提议废弃并最终移除用于设备配置流程的 zedboot。您可以改为通过基于 fastboot 的刷写来替换该流程，从而提高设备配置过程的稳定性和可靠性。

设计初衷

基于 Zedboot 的配置或“paving”通常用于引导 Fuchsia 设备。Zedboot 实际上是 Zircon 内核的一个实例，包含一组极少的驱动程序和服务。

fastboot 是一种通过 USB 和以太网与引导加载程序通信的机制。该组件还用于配置 Fuchsia 设备。这通常称为“刷写”设备。

基于 Zedboot 的铺砌工作流需要借助大量的 Fuchsia 系统才能正常运行，具体而言：

  • 内核
  • 驱动程序堆栈
  • 音量管理 (FVM)
  • 网络堆栈 (netsvc)

这些子系统必须正常运行，然后才能使用铺砌工作流配置 Fuchsia 系统。另一方面，fastboot 协议直接在引导加载程序中实现，不需要任何其他依赖项就能使用 Fuchsia 引导和预配设备。

使用 fastboot 的部分优势包括：

  • 适用于设备的单步配置流程，因为设备只需处于引导加载程序模式即可启动刷写过程。

    • 对于铺砌流程，zedboot 需要存在于设备分区（R、A 或 B 分区）上。如需在分区上获取 zedboot，需要使用刷写流程。最后，将 Fuchsia 系统铺到设备上后，zedboot 最终会被覆盖。

  • 无需通过 UDP 提供服务的启动服务器来获取用于预配的资源。只需一组预构建的映像资源。

  • 跨 Fuchsia 平台不同版本和分支的兼容性和支持。避免需要进行会影响开发者和平台发布流程的大规模更改。

  • 不需要在构建时仔细替换要在 Fuchsia 设备的 Recovery (R) 分区中运行的映像。

基于 Zedboot 的配置存在的一些问题如下：

  • 当 FVM 更改格式（例如 RFC-0005 Blobfs 快照中记录）时，需要对 Zedboot 进行相应的前滚更改。设备需要使用其他 zedboot 版本进行引导，以防止用户覆盖具有不兼容版本的设备 FVM 分区。
  • 当用户在 Fuchsia 分支之间切换时，不兼容的驱动程序版本、blobfs 或 fvm 版本可能会让开发者意外失败。
  • 作为前提条件，您需要使用 fastboot 将 Zedboot 刷写到设备上的某个分区。因此，用户在铺路前需要执行刷写步骤。
  • 通过 Zedboot 公开的 Fuchsia 表面区域公开了配置设备不需要的额外功能，因此存在安全风险。

围绕“fastboot”来简化配置过程有利于开发者工作流程、整合所有 Fuchsia 设备的配置，并解锁平台底层区域（如存储层）中的变化。

背景

Zedboot 版本控制

铺路需要 Fuchsia 设备与执行铺砌工作流的主机之间的 Zedboot 版本兼容性，以及 Fuchsia 设备与主机发送的映像之间的 FVM 格式兼容性。

当 FVM 和 zedboot 版本推出时，这些版本控制限制是开发者的一个重要痛点，特别是对于可能在分支之间切换的开发者（这也意味着设备经常在较新版本的 FVM 或 Zedboot）之间切换。

当开发者需要跨 Zedboot 版本边界降级设备时，会出现主要问题；在这种情况下，开发者需要先在设备上重新初始化 Zedboot，这需要重新刷写设备或执行两步铺砌序列，其中会尽最大努力重新计算 Zedboot 本身，而忽略版本匹配。对于升级路径，开发者可以选择使用标准系统无线下载 (OTA) 更新过程。

fastboot 版本控制

fastboot 还具有版本兼容性要求，由于在配置过程中需要写入额外的 Fuchsia 映像或文件，因此在某些情况下，必须更新引导加载程序以支持新的映像格式。

但是，与对更高级存储格式（例如 FVM）的更改相比，这种格式更简单且更稳定。例如，对引导加载程序所做的任何更改都可以通过 OTA 或刷写工作流通过 fastboot 进行处理。在大多数情况下，无需更改引导加载程序即可添加额外的映像。

设计

Fuchsia 产品的引导加载程序中正式支持 fastboot。它现在用于将 Fuchsia 映像配置到设备上。

实现

在弃用阶段之后，Zedboot 将从配置工作流和相关文档中移除。

实现会先弃用，然后再进行迁移。 因此，使用 paving 的各种脚本和开发者工具将如下所示：

  • 在 Fuchsia SDK 中标记为已废弃。
  • 更新为在使用铺砌时显示警告。
  • 已迁移到 SDK 中已有的刷写工具。
  • 移除。

性能

系统不会影响性能。

安全注意事项

废弃和移除 Zedboot 减少了整体安全问题。 这主要是操作员可用的广泛攻击面和控制级别，包括对底层文件系统的访问权限。

fastboot 已通过相应的安全审批流程，并已获准用于配置 Fuchsia 正式版设备。

隐私注意事项

与安全一样，移除 Zedboot 可以减少隐私问题，并且 fastboot 已获准用于生产设备。

测试

目前，Fuchsia 的开发者使用基于 fastboot 的配置。Fuchsia CI/CQ 系统中的适当基础架构将请求添加对基于 Fastboot 的预配的支持。这样可以确保定期测试 fastboot 流。

文档

需要更新开发者工作流程的文档，以反映基于刷写的新流程。

缺点、替代方案和问题

缺点

主要缺点是废弃并迁移了现有的铺砌脚本和工作流以使用刷写。

除了已提供支持的 U-Boot 之外，还需要承诺在其他 Fuchsia 引导加载程序中支持 fastboot。这意味着，随着在 Fuchsia 中启动新开发板，在早期启动期间需要支持 fastboot。

  • Intel NUC 产品上的 Gigaboot 引导加载程序尚未完全支持，但正在开发中：https://fxbug.dev/42147743: NUC: support full device flashing。

  • SeaBIOS 是 qemu 的默认引导加载程序，但 qemu 不支持铺砌工作流。因此，无需支持 fastboot。

  • Coreboot 用于在 Pixelbook 设备上启动 Fuchsia。铺砌是 Pixelbook 设备唯一支持的配置流程。可通过使用 depthcharge 载荷机制支持 fastboot。

其他注意事项和注意事项

在编写 RFC 时，我们假设主要工作流是将 Fuchsia 作为主要操作系统的设备进行配置。但是，对于通用 x64 系统（例如 Intel NUC），Zedboot 支持设置分区表以支持此用例。

  • fastboot 支持写入 GPT 表。不过，此处的首选方法是使用 fastboot 编写安装程序或恢复载荷，并使用它执行 Fuchsia 系统的初始引导。

Zedboot 还可用于网络启动（从网络中启动设备）。

  • fastboot 具有一个支持映像本地启动的 boot 命令。可进行扩展，以支持类似 netboot 的功能。
  • 或者利用深度费用设施来支持在特定硬件目标上执行网络启动。

刷写操作会擦除设备上的 FTL（闪存转换层）状态。

  • 能够跟踪一段时间内的 FTL 磨损均衡数据对某些团队来说是有用的信息。fastboot 支持允许实现某些产品专用命令的 oem 子命令。在这里，您可以选择通过 fastboot oem 导出 FTL 信息。

mexec 是一个流程，它允许使用新内核和启动映像软重新启动系统。移至基于 fastboot 的预配流程不会影响此功能。

现有艺术和参考资料

对于使用 Fastboot 进行配置的设备，可以有大量的相关技术知识。下面列出了两个示例：

Android

Android 设备完全依赖于基于 fastboot 的流程（如此处所述）。

随着 Android 设备进行各种升级和变更，基于 fastboot 的刷写和配置可以为引导系统以及将系统恢复到出厂状态提供一致的开发者流程和体验。

利纳罗

Linaro 是一个联盟，致力于资助和推广围绕加速 Arm 生态系统中的产品部署的各种项目。fastboot 是在各种 Arm 开发板（如 96board）中配置 linaro Linux 固件时使用的通用协议和方法。