📚 课程目录第2章启动链基础

2. 启动链基础

Android 设备的启动并不是“一按电源键就进系统”这么简单。它是一条由多个阶段首尾相接组成的启动链：每一级固件或引导程序在把控制权交给下一级之前，先验证下一级的完整性与合法性，验证通过才跳转执行。这条链从芯片内部固化的 BootROM 开始，经过 SPL、U-Boot/LK/ABL、TEE、Kernel，最终到达 init 与 system 分区。理解这条链，是理解 Android Verified Boot（AVB）的前提。

一、核心原理：信任根与逐级验证

启动链的本质是信任传递。信任必须有一个不可被篡改的起点，称为信任根（Root of Trust, RoT）。在 Android 设备上，这个起点通常是芯片内固化的 BootROM 代码，以及烧写在一次性可编程（OTP/eFuse）区域的公钥哈希。BootROM 无法被软件修改，因此它验证过的对象才值得信任。

信任传递遵循一个固定模式：上一级持有下一级的公钥或公钥哈希，用它对下一级镜像做签名验证；验证通过后，把执行权交给下一级，同时把“已验证”这一事实向下传递。任何一级验证失败，启动链就应停止或进入受限模式，而不是继续执行可疑代码。

信任链的关键不是“谁先运行”，而是“谁验证谁”。BootROM 验证 SPL，SPL 验证 U-Boot/ABL，ABL 验证 boot、dtbo、vbmeta 与 TEE，Kernel 再通过 dm-verity 验证 system 分区。每一环都依赖上一环提供的信任。

二、启动阶段与信任传递关系

下面这张图展示了从 BootROM 到 system 分区的完整启动链，以及每一级之间的验证关系。图中实线箭头表示控制权跳转，虚线箭头表示“验证/信任传递”方向。

三、各阶段职责与验证对象

不同厂商的引导程序名称不同，但职责高度相似。下表梳理了各阶段的主要任务与验证对象。

阶段	运行位置	主要职责	验证对象
BootROM	芯片内部 ROM	初始化最小硬件，加载并校验 SPL	SPL 签名 / 公钥哈希
SPL	SRAM	初始化 DRAM，加载主引导程序	U-Boot / LK / ABL
U-Boot / LK / ABL	DRAM	加载 boot、dtbo、vbmeta、TEE，进入 fastboot 或正常启动	boot、dtbo、vbmeta、TEE
TEE	安全世界	提供密钥存储、安全启动、DRM 等可信服务	由主引导程序验证后加载
Kernel	DRAM	挂载分区，启用 dm-verity 校验 system	system、vendor 等分区
init	用户空间	解析 init.rc，启动 zygote 与系统服务	依赖内核已建立的验证结果

四、典型场景：一次正常启动的日志片段

在串口日志中，可以清楚看到信任传递的痕迹。下面是一段简化后的启动日志：

[BootROM] verify SPL signature ... OK
[SPL] DRAM init done, load U-Boot ... OK
[ABL] verify vbmeta ... OK
[ABL] verify boot ... OK
[ABL] verify dtbo ... OK
[ABL] load TEE ... OK
[Kernel] dm-verity: verified boot hash tree
[init] Starting service 'zygote' ...

如果其中任何一步失败，例如 verify boot ... FAIL，设备通常会进入 fastboot 或显示红色警告，而不是继续启动。这正是 AVB 在启动链中发挥作用的位置。

五、常见误区与复盘

误区一：认为解锁 Bootloader 后就没有验证。解锁只是允许刷入自定义镜像，dm-verity 和 vbmeta 校验仍然存在，只是策略可能变为警告而非阻止。
误区二：把 TEE 当成普通应用。TEE 运行在独立安全世界，由主引导程序加载并验证，普通 Android 进程无法直接访问其内部。
误区三：忽略 vbmeta 的作用。vbmeta 分区保存了 boot、dtbo、system 等分区的哈希与签名信息，是 AVB 校验的“总目录”。
复盘要点：排查启动失败时，应按 BootROM → SPL → 主引导程序 → Kernel → init 的顺序逐级确认，先看串口日志中哪一级验证失败，再定位对应镜像或密钥。

记忆口诀：BootROM 是根，SPL 搬内存，ABL 验 vbmeta，TEE 管密钥，Kernel 查 system，init 起服务。每一级只信任上一级验证过的结果。