RFC-0170：從更新套件中移除二進位映像檔

摘要

為了收回系統空間，我們必須分割更新套件。至少開啟 單一空間限制產品，可以省下約 14 MiB。無微小的改變 而且需要的是逐步石頭發布根據 RFC 103，所有 需要自己的 RFC。此 RFC 詳細說明 套件格式。

提振精神

無線更新 (OTA) 機制是一種機制 ，以在執行中的裝置上升級 Fuchsia 版本。如果更新 時，system-updater 會擷取 更新套件。如何擷取套件 表示套件內容會寫入 BlobFS，並防止 例如垃圾收集update 套件含有映像檔 (例如復原程序) 映像檔和 Zircon Boot 映像檔)，也具有 Zircon 保留空間 以及其他要下載的套件清單，才能完成更新作業。

目前，Furchsia 裝置必須儲存每張圖片的兩份副本：

1. 位於目的地分區 (例如 ZIRCON_A) 中的一個副本， 測試的裝置使用時間
2. 一個 blobf 中的副本，因為圖片是以 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

設計

目前更新套件是包含映像檔的套件 擷取更新套件時，就會擷取並寫入 blobf。

建議您從更新套件提取映像檔，然後將每張圖片放入更新套件中 各自的套件。

這與現行的 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」是使用此 RFC 定義的格式時 新推出的版本屬性現在可以簡化作業中 日後需要的大量元素此模式已被用於 SWD 堆疊的其他位置 並能與 serde 妥善整合

system-updater 會剖析資訊清單，判斷映像檔是否需要 會被擷取 (取決於具有對應雜湊的檔案是否在 合適的版位)。系統會擷取已變更的每張圖片 寫入其分區，然後再從 BlobFS 收集垃圾。如果圖片 就不會覆寫 zircon 分區。

包含圖片大小和雜湊值，以用於驗證檢查。雜湊 是圖片檔案的 SHA256 雜湊值，以十六進位表示。由於分區 跨裝置變數，我們也必須知道 比較。網址含有 Merkle 雜湊。梅克爾雜湊較複雜 所以選擇了 SHA256 雜湊以加快比較速度。

我們建議進行 OTA 的程序如下：

1. 下載更新套件
2. 剖析含有更新圖片套件參照的新中繼資料檔案
3. 針對檔案中列出的每張圖片，只要圖片與 並在非使用中的分區上指定的 Zircon 分區映像檔 繼續。中繼資料檔案包含圖像的雜湊和大小 ( 映像檔大小不等於分區大小)，我們可以快速比較 非使用中分區上的映像檔雜湊。其他：
   1. 擷取要寫入圖片的圖片套件 BlobFS 且會處理完整性檢查。將套件新增至 保留索引
   2. 寫入分區。
   3. 垃圾收集 (從保留索引中移除套件) BlobFS 以收回空間。
4. 繼續下載更新作業中指定的其他套件 並完成 OTA 程序。

變更更新套件的結構可讓我們解決問題 限制問題。先寫入 BlobFS，然後進行垃圾收集，我們就能 善用 Google Cloud 提供的 目前儲存空間架構

實作

如要對更新套件進行這項變更，我們必須執行三個階段版本： 首先處理目前更新套件格式的超集和 update 套件的格式，第二個版本則只產生新格式 最後一個版本：用於停止處理舊版更新版本的邏輯 套件。

第一階段 system_updater 將進行修改，以便成功剖析 原始更新套件格式和此 RFC 中提議的修改格式。 MOS 仍會產生採用原始格式的更新套件。這個版本 含有這件作品將標示為踏板，確保所有 Fuchsia 裝置會收到 system_updater，該程式可以剖析新格式 才會收到使用新格式的更新套件。

在第二階段中，MOS 將開始使用新的 格式。

在第三階段，一旦我們確信沒有任何裝置需要復原至 採用原始更新套件格式的發布版本，system_updater 就會 已修改，移除對原始更新套件格式的支援。

如果我們未暫存版本，則裝置只能解讀目前版本 如果接收到的更新套件，更新套件的版本將會變得模糊 套件。我們需要將第一階段版本標示為「步行石」 確保所有裝置都能通過該版本。

更新套件的使用者需瞭解階段版本。已知 使用者就是安全性 — 查看 vis Scrutiny、MOS、產品組裝和軟體 提交。

成效

預計不會出現重大變化。

我們必須對圖片進行雜湊處理並加以比較。在最理想的情況下， 雜湊一致，因此不須花時間擷取或寫入。在 最糟糕的情況，當所有圖片都發生變更時，我們仍需要下載 位元組數

安全性考量

Scrutiny (我們的建構時間安全性分析工具) 會分析更新套件， 從中擷取 ZBI。我們需要更新 Scrutiny 測試，以反映 更新套件中 ZBI 的新位置。

圖片的完整性檢查不會改變。我們會繼續使用 與擷取更新套件的方法相同，而 update 套件包含 系統會強制執行映像檔套件和所有其他安全屬性的雜湊 並在裝置重新啟動新系統時驗證開機程序。

隱私權注意事項

此 RFC 不會對映像檔的建立或內容造成任何變更。 只有放送順序，因此不會影響 隱私權。

測試

我們已針對更新套件和 System-updater。我們需要延伸這些測試，以從 目前的更新套件版本和第一個版本 還是階段 1000第二個版本需要測試 處理更新套件和新版本的中繼版本 更新套件的一部分作業完成後， 進行中介測試，並以舊的 更新套件一律會失敗。

說明文件

我們將需要更新套件 說明文件和 OTA 文件應核准這項變更。

缺點、替代方法、未知

其他替代方案的設計完全不會將圖片寫入 BlobFS。

最簡單的方法是將圖片直接貼到其分區中， 然後透過 blobf 收集更新套件，最後再下載 屬於保留索引的一部分套件 blob。這個替代方案相當簡便 避免產生重複的寫入作業，也不需要踏出第一步 版本。不過，我們無法保證一定能進一步修正。如果更新 裝置可能會完全無法更新，

還有一種替代方案會將映像檔保留在更新套件中， 更新套件 更特別， 我們可以避免 同時將圖片儲存至 blobf這個設計將使得傳統需求 但需要對更新套件進行大量變更 system-updater 邏輯，區分更新套件的處理工作，以及 處理「正常」套件我們相信，建議的設計單純是重構 更新套件，而不是採用特殊處理邏輯。

既有技術

更新套件的設計是 先前記錄的 fuchsia.dev 上。