RFC-0170：从更新软件包中移除二进制映像

摘要

为了回收系统空间，我们必须拆分更新软件包。至少开启 一个空间有限的产品，我们将节省约 14MiB。这是一项非常重要的更改 需要通过铺垫石进行发布根据 RFC 103，所有 基础版本需要自己的 RFC。此 RFC 详细说明了新更新 文件包格式。

设计初衷

无线下载 (OTA) 更新是一种机制 用于升级正在运行的设备上的 Fuchsia 版本。如果更新 系统更新程序会提取 更新软件包。提取软件包 则意味着在将包的内容写入 BlobFS 时， 垃圾回收。更新软件包中会包含映像 映像和 Zircon 启动映像），它们还在 Zircon 上预留了空间 分区，以及要下载的其他软件包的列表以完成更新。

目前，Fuchsia 设备必须存储每张图像的两个副本：

1. 目标分区（例如 ZIRCON_A）中的一个副本， 设备在运行时使用的数量。
2. blobfs 中的一个副本，因为图片以 blob 的形式传送给设备 该更新软件包中

通过保护图片免遭垃圾回收影响，更新保证能够向前 进度（如果中断）。向前推进是非常重要的 更新系统的保证。然而，在空间有限的产品上，写作 将映像写入磁盘分区和 BlobFS 时预算不够理想。

映像写入是 OTA 流程中的倒数第二个步骤 切换活跃分区并重新启动进入新分区 系统映像在下一次更新之前，内核、固件和恢复映像 防止被垃圾回收和删除。对图片重新排序 因此我们可以先对 BlobFS 中的图片进行垃圾回收， 在 OTA 中下载大部分软件包，并收回 供其他软件包使用更改 SWD 设计以移除重复项 复制图片有可能节省大量空间， 在某些 Fuchsia 设备上价格较高。

为了在 OTA 期间对二进制映像进行垃圾回收，同时 为了确保取得进步，我们需要更改 update 软件包。

利益相关方

教员：hjfreyer@google.com

审核者：

• 软件交付：wittrock@google.com、jsankey@google.com
• MOS：gtsai@google.com
• 安全：ampearce@google.com
• 产品装配：awolter@google.com
• 版本：billstevenson@google.com

设计

目前，更新软件包也包含 在提取更新包时提取并写入 blobfs。

我们提议从更新软件包中提取映像，并将每个映像放入 自己的软件包。

这完全符合我们当前的 OTA 流程和软件包格式， 需要更改更新软件包的格式。

为了引用这些新软件包，我们将在更新软件包中添加名为 images.json，其中包含描述映像软件包的元数据。示例 该文件为：

{
  "version": "1",
  "contents": {
    "partitions": [
      {
        "type": "zbi",
        "slot": "fuchsia",
        "size": 1,
        "hash": "0a",
        "url": "fuchsia-pkg://fuchsia.com/fuchsia-zbi/0?hash={merkle_hash}#path/to/fuchsia.zbi"
      },
      {
        "type": "vbmeta",
        "slot": "fuchsia",
        "size": 2,
        "hash": "0b",
        "url": "fuchsia-pkg://fuchsia.com/fuchsia-vbmeta/0?hash={merkle_hash}#path/to/fuchsia.vbmeta"
      },
      {
        "type": "zbi",
        "slot": "recovery",
        "size": 3,
        "hash": "0c",
        "url": "fuchsia-pkg://fuchsia.com/recovery-zbi/0?hash={merkle_hash}#path/to/recovery.zbi"
      },
      {
        "type": "vbmeta",
        "slot": "recovery",
        "size": 4,
        "hash": "0d",
        "url": "fuchsia-pkg://fuchsia.com/recovery-vbmeta/0?hash={merkle_hash}#path/to/recovery.vbmeta"
      }
    ],
    "firmware": [
      {
        "type": "",
        "size": 5,
        "hash": "0e",
        "url": "fuchsia-pkg://fuchsia.com/update-images-firmware/0?hash={merkle_hash}#path/to/firmware"
      },
      {
        "type": "bl2",
        "size": 6,
        "hash": "0e",
        "url": "fuchsia-pkg://fuchsia.com/update-images-firmware/0?hash={merkle_hash}#path/to/firmware"
      }
    ]
  }
}

version 属性定义应如何解释内容属性。 版本必须始终为“1”指定的格式时， 现在，引入版本属性可以简化 。此模式已用在 SWD 堆栈 并且可与 serde 很好地集成。

系统更新程序将解析清单，以确定是否需要对映像进行 已提取（根据具有相应哈希值的文件是否已存在于 相应的广告位）。系统会抓取每个已更改的图片 然后从 BlobFS 中回收垃圾。如果图片 images.json 中不存在的内容，则不会覆盖 zircon 分区。

映像的大小和哈希已包含在内，以用于验证检查。哈希值 是以十六进制表示的图片文件的 SHA256 哈希。由于分区是 不同设备间的差异化处理，我们还需要知道 比较。该网址包含 Merkle 哈希。Merkle 哈希比较复杂， 计算，因此选择 SHA256 哈希来加快比较速度。

我们提议的 OTA 流程如下：

1. 下载更新软件包
2. 解析包含更新图片软件包引用的新元数据文件
3. 对于该文件中列出的每张图片，如果该图片与 非活动分区上的指定 Zircon 分区中， 继续。该元数据文件包含图片的哈希值和大小（作为 映像大小不等于分区大小），我们可以快速比较 非活动分区上映像的哈希值。否则： <ph type="x-smartling-placeholder">
   </ph>
   1. 获取包含相应映像的软件包，该映像会将映像写入到 BlobFS，将处理完整性检查。将软件包添加到 保留的索引。
   2. 写入分区。
   3. 从保留的索引中移除软件包 BlobFS 以回收空间。
4. 继续下载更新中指定的其余软件包 更新软件包，并完成 OTA。

通过改变更新软件包的结构，我们可以解决 约束问题。先写入 BlobFS 并进行垃圾回收， 充分利用由 Google 提供的 存储架构

实现

要对更新软件包进行此项更改，我们必须具有三阶段版本： 首先处理当前更新软件包格式的超集， 更新软件包的格式，进行第二次发布以仅生成新格式， 以及停止处理旧版本更新逻辑的最终版本 软件包。

在第一阶段，系统会修改 system_updater，以便成功解析 原始更新包格式以及此 RFC 中建议的修改后的格式。 MOS 仍会使用原始格式生成更新软件包。此版本 将包含此作品标记为“踏板石”，以确保所有紫红色 设备会收到能够解析新格式的 system_updater 然后再收到使用新格式的更新包。

在第二阶段，MOS 会使用新的 因此 RFC 1001 提议的 RFC 1000 规范。

在第三阶段，我们确信任何设备都不需要回滚到 使用原始更新软件包格式的版本，那么 system_updater 将 进行了修改，移除了对原始更新软件包格式的支持。

如果我们不预演发布版本， 如果收到更新后的更新，则更新软件包的版本 软件包。我们需要将第一阶段的发布标记为“踏板” 以确保所有设备都能通过该 build。

更新软件包的用户需要了解分阶段发布版本。认识 用户分别是安全与审查、MOS、产品装配和软件 送货。

性能

预计不会出现重大变化。

我们需要对图片进行哈希处理并进行比较。在理想情况下， 哈希匹配，我们不需要花时间提取或写入它们。在 最糟糕的情况是所有图片都会发生变化，我们仍然需要下载并编写相同的 字节数。

安全注意事项

Scrutiny（我们的构建时安全分析工具）会分析更新包， 提取 ZBI 的数据我们将需要更新审查测试，以反映 ZBI 在更新包中的新位置

映像的完整性检查不会改变。我们将继续使用 提取更新软件包的方法相同，并且更新软件包中包含 会强制执行映像软件包的哈希值和所有其他安全属性 验证启动。

隐私保护注意事项

此 RFC 未对映像的创建或内容引入任何变更， 它们仅按其投放顺序进行，因此不会影响 保护隐私。

测试

我们已经有针对更新软件包的单元测试和端到端集成测试， 系统更新程序我们需要扩展这些测试， 从当前版本的更新软件包升级到第一个版本的中间版本 踏板释放。对于第二个版本，我们需要进行 同时处理更新软件包的中间版本和新版本 更新软件包的版本这项工作完成后，我们将移除 并测试具有旧格式的降级 OTA 是否 更新软件包始终会失败。

文档

我们需要更新更新包 文档和 OTA 文档。

缺点、替代方案、未知

替代方案是完全不将图片写入 BlobFS 的设计。

这种简单方法是将图像直接铺平到对应的分区， 对 blobfs 中的更新包进行垃圾回收，最后下载新的 包含在保留索引中的软件包 blob。这个替代方法很简单 可以避免重复写入，并且不需要台阶 发布。但是，我们不再保证您一定会取得进展。如果更新 中断，那么设备可能根本无法更新。

我们还可以将图片保留在更新软件包中， 比之前更特别的是：我们可以避免 将图像保存到 blobfs 中。这种设计无需 对更新软件包进行更改，但需要对 system-updater 逻辑，并且更新软件包的处理不同于 “normal”的处理软件包我们认为，提议的设计只是通过重构 更新软件包，而不是引入特殊的处理逻辑。

先前技术

更新软件包的设计 之前记录在 fuchsia.dev 上。