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 平台不同版本和分支的兼容性和支持。避免需要进行大规模更改，以免影响开发者和平台发布流程。

  • 无需在 build 时仔细替换映像，即可在 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 中标记为已弃用。
  • 更新为在使用 Paving 时显示警告。
  • 迁移到 SDK 中已提供的刷写工具。
  • 在弃用期结束后移除。

性能

对系统性能没有影响。

安全注意事项

弃用并移除 Zedboot 可减少安全方面的总体关注范围。 主要是指攻击面广度和可供操作员使用的控制级别，包括对底层文件系统的访问权限。

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

隐私注意事项

与安全性一样，移除 Zedboot 可减少隐私方面的顾虑，并且 fastboot 已获准用于生产设备。

测试

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

文档

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

缺点、替代方案和未知因素

缺点

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

此外，还需要承诺在 U-Boot 之外的其他 Fuchsia 引导加载程序中支持 fastboot，而 U-Boot 已经支持 fastboot。这意味着，在 Fuchsia 中启动新主板时，需要在早期启动阶段提供 fastboot 支持。

  • Intel NUC 产品对 Gigaboot 引导加载程序的完整支持尚未完成，但正在进行中：https://fxbug.dev/42147743：NUC：支持完整设备刷写。

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

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

其他注意事项

此 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 固件。