信任鏈驗證流程 (The Chain of Trust)

整個過程就像一場嚴格的接力賽，每一棒都必須從可信的上一位手中接過接力棒（信任），驗證無誤后，再跑自己的那段路，并把信任傳遞給下一棒

現在，我們來詳細解讀圖中的每一步：

第 1 棒：硬件信任根 → Bootloader

• 運動員（驗證者）：?芯片內置的只讀存儲器（ROM）代碼。這是“發令員”，絕對可信
• 接力棒（被驗證對象）：?第一階段 Bootloader（例如?XBL?或?ABL）
• 驗證規則：
  ①?ROM 代碼從硬件信任根（eFuse）?中讀取預先燒錄好的、OEM公鑰的正確哈希值
  ②?ROM 代碼從 Bootloader 鏡像中提取出“候選”的OEM公鑰
  ③?ROM 代碼計算這個“候選”公鑰的哈希值，并與 eFuse 中的正確哈希值進行比對
  ④?如果匹配，說明這個公鑰是合法的。ROM 代碼隨后用這個合法的公鑰去驗證 Bootloader 鏡像本身的數字簽名
  ⑤?簽名驗證通過，ROM 代碼才將執行權交給 Bootloader。至此，Bootloader 成為了一個“可信實體”

第 2 棒：Bootloader → vbmeta.img

• 運動員（驗證者）：?剛剛被驗證為可信的 Bootloader
• 接力棒（被驗證對象）：?vbmeta.img?鏡像
• 驗證規則：
  ①?Bootloader 從閃存上的?vbmeta?分區中加載?vbmeta.img?到內存
  ②?Bootloader 使用其內置的、剛剛被驗證為合法的?OEM公鑰，去解密?vbmeta.img?末尾的加密簽名，得到一個“聲稱的哈希值（A）”
  ③?Bootloader 再自己對?vbmeta.img?的實際內容計算出一個“計算出的哈希值（B）”
  ④?對比 A 和 B。如果 A == B，證明?vbmeta.img?確實來自OEM且未被篡改。Bootloader 現在信任?vbmeta.img?里的所有內容

第 3 棒：vbmeta.img → 其他分區（boot, system, vendor）

• 運動員（驗證者）：?內核（借助?vbmeta.img?提供的規則）
• 接力棒（被驗證對象）：?boot.img,?system.img,?vendor.img?等
• 驗證規則：
  ○?對于 boot.img：?Bootloader 直接讀取?vbmeta.img?中關于?boot?分區的哈希描述符。它計算?boot?分區的實際哈希值，與描述符中的值比對。匹配則加載內核
  ○?對于 system.img/vendor.img：
  ①?Bootloader 將控制權移交給已被驗證的 Linux 內核
  ? ??②?內核啟動后，會讀取?vbmeta.img?中關于?system?和?vendor?分區的哈希樹描述符，獲取到受信任的根哈希
  ③?內核利用?dm-verity?驅動，使用這個根哈希來實時驗證?system?分區中的每一個數據塊（4KB）。vendor?分區同理
  ④?任何對數據的篡改都會導致讀取失敗，從而保護系統的完整性

為什么這種設計很優秀？

1. 解耦 (Decoupling):?Bootloader 不需要知道如何驗證每一個具體分區，它只需要信任并驗證?vbmeta.img?即可。分區驗證策略（用哈希還是用哈希樹）的變更不需要修改 Bootloader 代碼
2. 靈活性 (Flexibility):?通過?vbmeta.img?可以輕松支持新的分區（如?product,?system_ext），只需將其描述符加入即可
3. 分權治理 (Delegation):?通過鏈式描述符，可以將不同分區的驗證權委托給不同的實體（例如 Google 驗證?system，OEM 驗證?vendor），實現了復雜的供應鏈安全模型