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 通訊協定會直接在 Bootloader 中實作，因此無須任何其他依附元件，即可使用 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 裝置和執行鋪面工作流程的主機之間，以及 Fuchsia 裝置和主機傳送的映像檔之間，提供 Zedboot 版本相容性。

在 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 為基礎的佈建作業支援。這可確保定期測試快速啟動流程。

說明文件

開發人員工作流程的說明文件需要更新，以反映新的刷新流程。

缺點、替代方案和未知事項

缺點

主要缺點是淘汰現有的鋪面指令碼和工作流程，並將其遷移至使用閃爍功能。

除了已支援的 U-Boot 之外，您也必須承諾在其他 Fuchsia 引導程式中支援 fastboot。也就是說，當新的電路板在 Fuchsia 中啟動時，需要在早期啟動期間支援快速啟動。

  • 我們正在努力支援 Intel NUC 產品上的 Gigaboot 引導程式，但目前尚未完成：https://fxbug.dev/42147743: NUC: support full device flashing。

  • SeaBIOS 是 qemu 的預設引導程式，但 qemu 不支援鋪面工作流程。因此，不需要支援快速啟動。

  • Coreboot 可用於在 Pixelbook 裝置上啟動 Fuchsia。鋪設是 Pixelbook 裝置唯一支援的佈建流程。您可以使用深度充電酬載機制支援快速啟動功能。

其他注意事項

這份 RFC 是以主要工作流程假設為前提編寫，該流程會將 Fuchsia 做為主要作業系統，用於裝置的佈建作業。不過，對於 Intel NUC 等通用 x64 系統，Zedboot 支援設定分割表，以便支援此用途。

  • Fastboot 支援寫入 GPT 表格。不過，建議您使用 fastboot 編寫安裝程式或復原酬載，然後用於執行 Fuchsia 系統的初始引導程序。

Zedboot 也用於網路啟動 (透過網路啟動裝置)。

  • Fastboot 提供 boot 指令，可支援本機啟動映像檔。這可以擴充為支援類似網路啟動功能的功能。
  • 或者，您也可以利用 depthcharge 中的設施，支援特定硬體目標的網路啟動。

閃燈作業會清除裝置上的 FTL (Flash Translation Layer) 狀態。

  • 追蹤 FTL 耗損平衡資料的能力對某些團隊來說是實用的資訊。fastboot 支援 OEM 子命令，可讓您實作特定產品專屬指令。您可以透過 fastboot oem 匯出 FTL 資訊。

mexec 是一種流程，可讓您使用新的核心和啟動映像檔，以軟體方式重新啟動系統。改用以快速啟動為基礎的建構流程不會影響這項功能。

既有技術與參考資料

在使用 Fastboot 進行裝置佈建的先前技術中，有大量相關技術。以下列舉兩個範例：

Android

Android 裝置完全依賴這裡所述的 Fastboot 流程。

隨著 Android 裝置經歷各種升級和變更，以 Fastboot 為基礎的刷機和佈建作業可為引導系統和將系統還原為原廠狀態提供一致的開發人員流程和體驗。

Linaro

Linaro 是一個聯盟，專門資助及推廣各種專案，以加速在 Arm 生態系統中部署產品。Fastboot 是常見的通訊協定和方法，用於在各種 Arm 開發和原型板 (例如 96boards) 中佈建 Linaro Linux 韌體。