| RFC-0075：淘汰以 Zedboot 為基礎的鋪路，以佈建裝置 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 以 Fastboot 為基礎，將裝置佈建標準化，並淘汰以 Zedboot 為基礎的鋪路。 |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2021-02-25 |
| 審查日期 (年-月-日) | 2021-03-12 |
摘要
本文件建議淘汰並最終移除裝置佈建流程的 zedboot。而是透過以 Fastboot 為基礎的刷機作業取代流程，進而提升裝置佈建程序的穩定性和可靠性。
提振精神
以 Zedboot 為基礎的佈建或「鋪路」通常用於啟動 Fuchsia 裝置。Zedboot 實際上是 Zircon 核心的執行個體，包含最少的驅動程式和服務。
Fastboot 是透過 USB 和乙太網路與開機載入程式通訊的機制。 這項工具也可用來佈建 Fuchsia 裝置。這通常稱為「刷機」。
以 Zedboot 為基礎的鋪路工作流程需要大量 Fuchsia 系統才能正常運作，具體來說：
- 核心
- 驅動程式堆疊
- 音量管理 (FVM)
- 網路堆疊 (netsvc)
這些子系統必須正常運作，才能使用鋪路工作流程佈建 Fuchsia 系統。另一方面，fastboot 通訊協定直接在開機載入程式中實作，不需要任何其他依附元件，就能啟動並佈建 Fuchsia 裝置。
使用 Fastboot 的優點包括：
裝置只需處於系統啟動載入程式模式，即可啟動刷機程序，因此裝置的單一步驟佈建流程。
- 如要執行鋪路流程，裝置分區 (R、A 或 B 分區) 必須有 zedboot。如要在分割區上取得 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 格式的相容性。
當 FVM 和 zedboot 版本推出時，這些版本控管限制會成為開發人員的一大痛點，尤其是可能會在分支版本之間切換的開發人員 (這也表示裝置會經常在舊版和新版 FVM 或 Zedboot 之間切換)。
主要問題是開發人員需要跨越 Zedboot 版本界線降級裝置；在這種情況下，開發人員必須先在裝置上重新初始化 Zedboot，這需要重新刷寫裝置，或是執行兩步驟鋪路序列，包括盡力重新鋪路 Zedboot 本身，並忽略版本不符的問題。開發人員可選擇使用標準系統無線 (OTA) 更新程序，進行升級。
Fastboot 版本管理
Fastboot 也有版本相容性規定，且由於需要寫入額外的 Fuchsia 映像檔或檔案，因此在某些情況下，必須更新開機載入程式，才能支援新的映像檔格式。
不過，相較於變更較高層級的儲存格式 (例如 FVM)，這個格式簡單且穩定許多。例如，開機載入程式的任何變更，都可以透過 OTA 或透過 Fastboot 進行的刷機工作流程處理。在大多數情況下，新增其他圖片時不需要變更開機載入程式。
設計
fastboot 已正式支援 Fuchsia 產品的開機載入程式。目前用於在裝置上佈建 Fuchsia 映像檔。
實作
經過淘汰階段後，Zedboot 會從佈建工作流程和相關文件中移除。
實作程序會先淘汰，然後進行遷移。 因此，使用鋪路功能的各種指令碼和開發人員工具將會：
- 在 Fuchsia SDK 中標示為已淘汰。
- 更新後，使用鋪路功能時會顯示警告訊息。
- 已遷移至 SDK 中現有的刷機工具。
- 在淘汰期結束後移除。
效能
系統效能不受影響。
安全性考量
淘汰並移除 Zedboot 可減少整體安全疑慮。主要是因為攻擊途徑廣泛，以及可供運算子使用的控制層級，包括存取基礎檔案系統。
Fastboot 已通過適當的安全核准程序，可使用於 Fuchsia 生產裝置的佈建作業。
隱私權注意事項
與安全性一樣，移除 Zedboot 可減少隱私權方面的疑慮，且 fastboot 已獲准用於生產裝置。
測試
Fuchsia 開發人員目前使用 Fastboot 進行佈建。系統會要求 Fuchsia CI/CQ 系統提供適當的基礎架構，以便新增 Fastboot 佈建支援。確保定期測試快速啟動流程。
說明文件
開發人員工作流程的說明文件需要更新，以反映新的刷機流程。
缺點、替代方案和未知事項
缺點
主要缺點是現有鋪路指令碼和工作流程會遭到淘汰，必須遷移至使用刷機。
此外，除了已支援的 U-Boot 之外，也必須承諾在其他 Fuchsia 開機載入程式中支援 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 韌體。