3. 启动流程与信任链

要理解度量启动(Measured Boot)在可信计算体系中的位置,必须先看清一台计算机从上电到操作系统接管控制权之间究竟发生了什么。启动不是一次“跳转”,而是一条由多个阶段首尾相接、逐级交接控制权的链条。每一级在把执行权交给下一级之前,都要先验证或记录下一级的身份,这就是“信任链”的物理含义。度量启动与验证启动(Verified Boot)共享同一条启动路径,区别只在于:验证启动在交接前做“判断并拦截”,度量启动在交接前做“记录并上报”。

一、启动阶段的划分

以典型的 x86 平台 UEFI 启动为例,从加电到操作系统内核运行,可以划分为若干职责明确的阶段。每个阶段都有独立的执行环境、存储介质和信任假设。

  • 上电与复位(Power-On / Reset):CPU 从复位向量取指,此时内存尚未初始化,可执行代码位于固件 ROM 或 Boot ROM 中。这是信任链的绝对起点,通常被称为信任根(Root of Trust)。
  • 固件阶段(SEC / PEI / DXE / BDS):UEFI 固件依次完成安全环境建立、早期内存初始化、驱动执行环境加载、启动设备选择。DXE 阶段会加载大量驱动,是攻击面最广的阶段。
  • 引导加载器阶段(Bootloader):如 GRUB、Windows Boot Manager,负责从磁盘读取内核镜像、initrd 与配置,并准备内核启动参数。
  • 内核阶段(Kernel):内核解压、建立页表、初始化子系统,随后挂载根文件系统。
  • 用户态初始化(init / systemd):启动用户态服务,最终进入登录界面。

这条路径的关键特征是“单向传递”:后一阶段完全依赖前一阶段提供的执行环境,因此前一阶段一旦被篡改,后续所有阶段的真实性都无法保证。

二、信任传递模型

信任传递模型描述的是“信任如何从不可变的硬件根,逐级扩散到可变的上层软件”。它包含三个要素:信任根、传递动作、以及传递时的判定依据。

信任根通常由硬件提供,例如 TPM 2.0 芯片中的 CRTM(Core Root of Trust for Measurement)、CPU 微码中的 Boot Guard、或 SoC 内的 Boot ROM。信任根的特点是“不可被软件修改”,因此它输出的第一个度量值具有锚点意义。

传递动作有两种典型形式:

  • 验证式传递:当前阶段用公钥验证下一阶段的签名,验证通过才移交控制权。失败则停机或回退。这是 Verified Boot 的做法。
  • 度量式传递:当前阶段计算下一阶段的哈希值,将哈希扩展(extend)到 TPM 的 PCR 寄存器中,然后无条件移交控制权。是否可信由远端挑战方事后判断。这是 Measured Boot 的做法。
信任传递的本质不是“让下一级变可信”,而是“让上一级的判断依据可被追溯”。验证启动把判断放在本地,度量启动把判断放在远端。

三、度量启动的定位

度量启动并不阻止任何代码执行,它只做一件事:把启动路径上每一个被加载的组件,按固定顺序计算哈希并扩展到 PCR 中。PCR 的扩展操作是单向的:PCR_new = Hash(PCR_old || measurement),因此最终 PCR 值唯一对应一条启动路径。

这决定了度量启动的定位:它是“证据生成器”,而不是“门禁”。它适合与远程证明(Remote Attestation)配合使用,由挑战方根据 PCR 值判断目标机器是否运行了预期软件栈。它也适合与磁盘加密(如 BitLocker)配合,用 PCR 值作为解封密钥的条件。

下面这张图展示了从固件到操作系统的启动阶段划分、信任传递方向,以及度量启动在每个交接点插入的位置。

启动阶段划分与信任传递链 上电/复位 Boot ROM / CRTM UEFI 固件 SEC/PEI/DXE/BDS 引导加载器 GRUB / BootMgr 操作系统内核 Kernel / initrd 用户态初始化 init / systemd M1 M2 M3 M4 TPM 2.0 — PCR 扩展与事件日志 PCR[0] 固件代码 PCR[1] 固件配置 PCR[4] 引导加载器 PCR[7] 安全启动策略 PCR[8-9] 内核/initrd Event Log 度量事件记录 远程证明(Remote Attestation) 挑战方发送 nonce → 目标机返回 PCR 值 + 事件日志 挑战方重放事件日志,比对 PCR 是否一致,判断启动路径可信性 图例 控制权传递 度量扩展 度量插入点

四、典型场景与参数关系

以 Linux 平台使用 systemd-boot + TPM 2.0 为例,一次完整的度量启动会经历如下关键动作。下表列出了各阶段对应的 PCR 寄存器与典型度量对象。

启动阶段 执行主体 度量对象 典型 PCR 传递方式
上电/复位 Boot ROM / CRTM 固件初始代码块 PCR[0] 度量后移交
UEFI 固件 SEC/PEI/DXE 固件驱动、配置、Secure Boot 策略 PCR[0-3]、PCR[7] 度量后移交
引导加载器 systemd-boot / GRUB bootloader 二进制、内核命令行 PCR[4]、PCR[8] 度量后移交
内核阶段 Linux Kernel 内核镜像、initrd、模块签名 PCR[8-9] 度量后移交
用户态初始化 systemd 关键服务配置、IMA 策略 PCR[10-12] 度量后移交

可以看到,PCR 的分配并非随意,而是遵循“同类对象归同类寄存器”的原则。PCR[0-7] 用于固件与安全启动策略,PCR[8-15] 用于操作系统与用户态。这种划分让远端挑战方可以按需选择验证范围:只验证固件完整性,或验证到内核,或验证到用户态服务。

五、常见误区与复盘

误区一:把度量启动当成验证启动。度量启动不会阻止篡改后的代码运行,它只记录“运行了什么”。如果只部署了度量启动而没有远程证明或解封策略,攻击者依然可以启动恶意系统,只是 PCR 值会变化。
误区二:认为 PCR 值可以直接比对。PCR 是扩展值,不是简单哈希。必须结合事件日志重放(replay)才能还原出具体度量了哪些组件。只拿到 PCR 值无法定位是哪一级被篡改。
复盘要点:设计度量启动方案时,先明确“谁来判断可信”。如果是本地判断,应使用验证启动;如果是远端判断,应使用度量启动并配套事件日志与证明协议。两者可以叠加使用,形成“本地拦截 + 远端审计”的双层防护。

理解启动阶段划分与信任传递模型,是后续设计 PCR 策略、事件日志格式和远程证明协议的基础。度量启动的定位始终是“证据链的起点”,它把不可见的启动过程转化为可验证的密码学证据,让远端挑战方能够对一台机器的启动路径做出可信判断。