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

RFC-0075：废弃了基于 Zedboot 的设备预配铺平
状态已接受
区域
  • 常规
说明

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

修改此 RFC

修改 RFC 元数据

摘要

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

设计初衷

基于 Zedboot 的预配或“铺设”通常用于引导 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 将从配置工作流和相关文档中移除。

实现将遵循弃用和迁移流程。因此，使用铺路的各种脚本和开发者工具将：

  • 在 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 不支持任何铺平工作流。因此，不需要快速启动支持。

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

其他注意事项和注意事项

在编写 RFC 时，我们假定主要工作流是将 Fuchsia 作为主要操作系统配置设备。不过，对于 Intel NUC 等通用 x64 系统，Zedboot 支持设置分区表以实现此用例。

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

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

  • Fastboot 有一个 boot 命令，支持本地启动映像。这可以扩展为支持类似于网络启动的功能。
  • 或者，利用 depthcharge 中的设施支持在特定硬件目标上进行网络启动。

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

  • 能够跟踪一段时间内的 FTL 磨损均衡数据对某些团队来说非常有用。fastboot 支持 oem 子命令，可实现特定产品专用命令。此时，可以通过 fastboot oem 导出 FTL 信息。

mexec 是一种流程，可让系统使用新内核和启动映像软重启。改用基于 Fastboot 的配置流程不会影响此功能。

在先技术和参考文档

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

Android

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

随着 Android 设备经历各种升级和更改，基于 fastboot 的刷写和配置可为启动系统和将系统恢复为出厂状态提供一致的开发者流程和体验。

Linaro

Linaro 是一个联盟，负责资助和推广各种旨在加速在 Arm 生态系统中部署产品的项目。Fastboot 是用于在各种 Arm 开发板和原型板（例如 96boards）上预配 Linaro Linux 固件的常用协议和方法。