背景
Fuchsia 從零開始設計，可支援及擴充經驗證的高強度啟動模型。在大多數使用驗證開機程序的系統中，驗證作業僅涵蓋最高特定權限等級的程式碼，且必須在某個時間點執行未經驗證的程式碼。Fuchsia 已在系統執行階段中進行驗證，因此「已驗證執行」這個名稱 (縮寫為 VX 或 FVX)。FVX 的目標是確保所有可執行的程式碼值得信賴。
除非另有指定，否則本文件使用「可執行程式碼」是指直接在硬體上執行的機器程式碼。可執行的程式碼不會是指採用沙箱機制、解譯或受限於衝突機制的程式碼。
範圍
本文件說明使用者建構類型 (除非另有指定) 驗證執行作業的一般原則和階段。硬體或產品的實作細節和政策決策不在說明範圍內。本文件著重說明核心驗證邏輯，並排除多層深入防禦機制。
安全性模型
VX 考慮採用兩種安全性模型：執行中的軟體模型和經過驗證的開機模式。
+------------------------------------------------------------------------------+
| |
| +---------------------------------------------+--------------------------+ |
| | | | |
| | +------------------+ +--------------------+ | +----------------------+ | |
| | | Recovery from | | Recovery from full | | | Mitigation against | | |
| | | physical attacks | | attacker control | | | vulnerabilities | | |
| | +------------------+ +--------------------+ | +----------------------+ | |
| | Verified boot model | Running software model | | |
| +---------------------------------------------+--------------------------+ |
| |
| Verified execution |
+------------------------------------------------------------------------------+
驗證開機程序安全性模型
驗證開機程序安全性模型有兩個層面：從實體攻擊進行復原，以及從完全攻擊者控制的復原。實體攻擊絕大部分不在本總覽的討論範圍內，但已大致上來說，具有實體存取權的攻擊者可以完成的攻擊，比擁有完整控制的攻擊者更少。
完整攻擊者控制 (FAC) 可讓攻擊者執行他們選為「主管」或「核心」模式的程式碼 (這裡不會考慮效能較強大的執行模式)。這個安全性模型的防禦者目標是透過消除不信任的狀態 (程式碼和資料)，避免攻擊者在重新啟動後持續控制權限狀態。
Fuchsia 對已驗證的開機安全性模型的回應方式，是讓電腦只要重新啟動，即可從任何遭入侵的模式中復原。開機時，Fuchsia 以遞迴方式驗證執行程序
- 所有執行的程式碼都值得信任，並根據一個「錨點」(例如 ROM 中的程式碼) 提供。
- 根據相同的錨點，所有作為輸入程式碼的資料都值得信賴。
此保證可讓系統完全移除不可信任的狀態，即使出現意外的惡意漏洞也一樣。
防復原
驗證的啟動模型假設攻擊者可將大量儲存空間內容替換為自行選擇的內容。在這個模式下，如果重新啟動後可能會遭人利用的安全漏洞，那麼在沒有硬體式反復原機制的情況下，一律不可能修補漏洞。如果沒有這種機制，攻擊者可以刷新安全漏洞的舊作業系統版本，以便通過已驗證的啟動檢查，然後重播需要重新開發 FAC 的漏洞。硬體式反復原機製完全拒絕啟動這個安全漏洞的 Fuchsia 版本，徹底避免這種情況在安全漏洞修補後啟動。
執行軟體模型
在這個模式下，軟體會執行，而攻擊者會試圖利用軟體中的安全漏洞，控管執行中的軟體，通常是透過建立軟體有惡意的輸入內容。在這個安全性模型中，防禦者的目標是透過強化程式碼來防範惡意輸入內容，藉此解決或降低潛在的安全漏洞。
Fuchsia 對執行中的軟體模型的回應是限制在可信任的程式碼執行。(「可靠性」的定義稍後會進一步說明)。
原則
以下僅列舉部分內容，協助您瞭解如何實作 Fuchsia 驗證執行程序：
程式碼和相關聯的唯讀資料應根據意圖政策進行驗證。每種程式碼、產品或建構類型的政策可能不同，但所有程式碼都應繫結至政策。一個簡單的政策範例：「除非程式碼已由受信任的方數位簽署，否則無法執行程式碼。」
- 系統沒有預設或備用政策。
- 政策不允許一次性側載程式碼 (不含「雪花」)。
- 政策極少允許及時編譯 (JIT)。
輸入政策驗證和加密配置的輸入內容應盡可能簡單。
- 政策驗證作業不應要求剖析不受信任的複雜資料。
已驗證的執行作業可在各種硬體上實作，但強烈建議使用硬體不可變更的信任錨點和可防竄改的儲存空間 (例如，儲存只能透過韌體修改 (而非核心) 修改的復原索引)。
驗證階段
使用雜湊和簽署模式進行驗證後，程式碼和資料就會視為可信：資料會在訊息 + 簽名的組合中載入，並使用信任的公開金鑰進行驗證。訊息內含大型程式碼或資料 blob 的加密編譯雜湊值，經過雜湊處理及驗證，才能視為可信。
第 0 階段：從硬體到第一個系統啟動載入程式
階段 0 是由硬體到軟體轉換所構成。已驗證的執行作業無法抵禦硬體攻擊，因此為了本文件的目的，我們會假設硬體已受信任。在這個階段，不可變更的程式碼會依據不可變更的信任錨點 (例如一次性程式化 (OTP) 記憶體中的公開金鑰) 驗證第一個系統啟動載入程式。詳細資料會因硬體而異。
第 1 階段：第一個系統啟動載入程式至主系統啟動載入程式
首次系統啟動載入程式通過驗證後，系統會信任該系統，驗證並執行啟動系統所需的其他軟體。這可能是軟體映像檔鏈結，每個映像檔都會驗證並執行下一個映像檔，也可能是類似樹狀結構的流程。這個階段也適用於硬體。
第 2 階段：從主系統啟動載入程式到預先授權程式碼
主要系統啟動載入程式負責驗證預先授權程式碼，也就是產品授權明確核准做為該產品核心部分執行的所有程式碼。預先授權的程式碼可以直接在硬體上執行 (也就是沒有沙箱)，並包含 Fuchsia 系統的所有必要元素 (例如 Zircon 核心、套件管理系統、驅動程式)。 AVB
從主系統啟動載入程式委派
系統啟動載入程式驗證 ZBI 後，會有兩個重要點委派驗證責任。
- 通過驗證的 ZBI 會驗證套件管理系統。具體來說，ZBI 會從系統啟動載入程式取得套件管理系統的精確描述，並強制執行所有適用於該系統的政策。
- 驗證完成後，套件管理系統會負責驗證不屬於 ZBI 或套件管理系統中的所有其餘預先授權程式碼。
直接驗證與間接驗證
直接驗證流程是精確說明獲準執行的軟體 (例如使用套件的加密編譯雜湊)，以明確說明要信任的「內容」。間接驗證會指定要信任的對象，並將「什麼」交由委派授權人處理。當套件管理系統以 VX 政策強制執行者的身分接管後，就可能使用間接驗證來允許即時推送軟體，不必完成完整的系統更新並重新啟動。為維護信任鏈，間接驗證程序涉及的元件和設定 (ZBI、套件管理系統) 必須一律直接驗證。
請注意，直接驗證的說明內容可能相當複雜。如果簽名附加至某個檔案雜湊，而該檔案含有更多雜湊，系統仍會直接驗證所有經雜湊處理的內容。
第 3 階段：非預先授權程式碼
如果產品擁有者都未授權程式碼和簽署授權，該程式碼的驗證狀態與靜態政策相同。某些特定用途的裝置可能完全無法執行非預先授權的程式碼。靜態政策的強制執行是套件管理系統和元件架構的角色。
強而有力的意圖
意圖有強烈意圖的非預先授權程式碼，是指使用者擔任管理員角色的套件已明確授權在特定環境中執行的程式碼。這類非預先授權程式碼可直接在機器上執行，且環境與預先授權的程式碼隔離。意圖強度不足且非預先授權的程式碼是指使用者並非具備管理員角色的使用者會意外載入或授權的程式碼 (例如網頁載入的 JavaScript)。意圖不良的非預先授權程式碼必須採用沙箱機制、解譯或嚴格的限制機制。
實作
下列 Fuchsia 系統必須強制執行經過驗證的執行政策。
主系統啟動載入程式
系統啟動載入程式主要實作時仰賴 Android 驗證開機程序以進行驗證，以及防止核心復原。
BlobFS
BlobFS 是針對驗證執行作業所打造的加密編譯、內容定址檔案系統。BlobFS 是可執行程式碼及相關聯唯讀資料的唯一儲存系統 (預先核心程式碼、核心及其Bootfs) ramdisk ，且全部都儲存在 ZBI 中。BlobFS 中的每個 blob 都是以雜湊 (Merkle 根) 表示及存取，而 Merkle 樹狀結構結構則允許隨機存取 blob。攻擊者無法在不變更雜湊的情況下變更 blob，所以無法進行計算。
在第二階段中載入 BlobFS 後，驗證預先授權程式碼的方法就是檢查每個載入的 blob 雜湊的簽章，並確保 blob 內容與雜湊相符。BlobFS 執行內容驗證，並將簽名檢查委派給套件管理系統。
套件管理系統
套件管理系統又稱為軟體交付 (SWD) 堆疊，會在 BlobFS 上新增層，讓程式設計人員更容易處理 blob。SWD 堆疊會將描述套件的 Merkle 根目錄 (特別是套件中繼中繼.far 的 Merkle 根) 轉譯成使用者可理解的套件名稱。如有任何套件內容變更，meta.far 的 Merkle 根目錄就會變更。為求簡潔，本文件將使用「套件雜湊」參照套件的中繼.far Merkle 根目錄。
SWD 堆疊會管理名為「系統映像檔」的特殊套件，其中包含所有基本套件的雜湊清單。當套件管理系統在階段 2 中載入時，ZBI 會驗證系統映像檔套件，因此所有基礎套件都直接經過驗證；也就是說，開機後不需進行簽署檢查。針對部分特定用途的裝置，您可以設定 SWD 堆疊，只讓具備執行權限的記憶體載入基本套件；也就是說，裝置只會執行直接驗證的程式碼。
如果是間接驗證的程式碼 (以下簡稱「宇宙套件」)，受信任的公開金鑰和其他中繼資料會納入已驗證開機簽名所涵蓋的位置 (例如 ZBI 或基本套件)。每次載入套件時，從這類作者處下載的套件都必須透過簽章和內容雜湊進行驗證，而不是在下載時檢查簽名一次。「Backstop 版本」中繼資料可能包含在直接驗證的資料中，以確保直接和間接驗證的套件都受到硬體反復原保護機制所涵蓋。
SWD 堆疊也會負責下載系統更新。其中包含許多控管措施，可在裝置重新啟動 (並因此進行驗證) 更新前，避免執行中的任何 blob 提供給執行中的系統。
元件架構
套件是軟體「發布」的單位，而元件是 Fuuchsia 的軟體「執行」的標準單位。這項差異會導致多數 Fuchsia 元件不會直接與 SWD 堆疊互動。而是 SWD 套件解析器的主要客戶是元件架構，其中包含多個元件解析器，可委派給 SWD 堆疊載入程式碼和資料。部分元件解析器僅限於基礎套件，有些則會允許存取宇宙套件。如同其他 Fuchsia 功能，這些解析器會在元件資訊清單中轉送，以便進一步控管及稽核使用情形。例如，間接驗證程式碼只能用於特定環境。