4. Measured Boot原理
Measured Boot（度量启动）解决的是“启动过程中到底发生了什么、是否可被事后验证”的问题。它并不直接阻止某个组件运行，而是在每个启动阶段对即将执行的代码和关键配置做密码学哈希，把结果按固定顺序扩展到 TPM 的 PCR（Platform Configuration Register）中，同时把“谁被度量、度量值是多少”记录到事件日志。这样，本地或远程验证方就能重放日志、复算 PCR，判断启动链是否与预期一致。
一、核心原理：先记录，再验证
度量启动的核心动作可以概括为“哈希—扩展—记录”。以 UEFI 固件启动为例，CRTM（Core Root of Trust for Measurement）通常是固件中不可变的度量根。它先度量自身或下一阶段组件，得到摘要后写入 PCR，并把该事件追加到 TCG 事件日志。后续每个阶段继续度量下一阶段，形成一条从固件到引导程序、再到内核与关键配置的信任链。
PCR 扩展不是覆盖写，而是：
PCR_new = Hash(PCR_old || Digest_measured)这意味着 PCR 的最终值依赖“初始值 + 所有历史度量值 + 扩展顺序”。即使两个系统最终运行了相同组件，只要启动路径或度量顺序不同，PCR 值也会不同。因此 PCR 不是简单的“文件哈希列表”，而是启动历史的累积指纹。
关键点：Measured Boot 提供的是可验证性（Verifiability），不是强制性阻断。它回答“启动链是否被改动”，而不是“是否允许启动”。
二、与 Secure Boot 的区别
Secure Boot 和 Measured Boot 经常同时出现，但职责不同。Secure Boot 依赖固件中的密钥数据库（PK、KEK、db、dbx）验证启动组件的签名，签名不受信任就拒绝执行，属于“执行前拦截”。Measured Boot 则对实际加载的组件做度量并记录，不依赖签名策略来决定是否放行，属于“执行时记录、执行后验证”。
| 对比维度 | Secure Boot | Measured Boot |
|---|---|---|
| 核心目标 | 阻止未授权代码启动 | 记录启动链并支持远程证明 |
| 判断依据 | 签名与证书链 | 哈希度量值与事件日志 |
| 失败表现 | 启动被拒绝 | 启动可继续，但 PCR 与预期不符 |
| 典型输出 | 允许/拒绝 | PCR 值 + TCG 事件日志 |
| 验证时机 | 组件执行前 | 启动后由本地或远程验证方重放 |
两者并不互斥。Secure Boot 可以保证只有签名合法的组件能进入度量流程，Measured Boot 则把这些组件的实际度量结果记录下来，供远程证明使用。缺少 Secure Boot 时，度量仍可进行，但攻击者可能让未授权组件先运行；缺少 Measured Boot 时，Secure Boot 只能做本地拦截，难以向远程方证明“我到底启动了什么”。
三、度量事件与事件日志
TCG 事件日志由一系列事件组成，每个事件通常包含：事件类型、PCR 索引、度量摘要、事件数据。常见事件类型包括 EV_S_CRTM_VERSION、EV_EFI_BOOT_SERVICES_APPLICATION、EV_EFI_VARIABLE_DRIVER_CONFIG、EV_SEPARATOR 等。事件日志的价值在于：验证方可以按顺序重新计算 PCR，并与 TPM 中实际 PCR 值比对。
例如，一次典型的 UEFI 启动日志片段可能如下：
PCR[0] EV_S_CRTM_VERSION digest=3f2a... data="UEFI 2.8"
PCR[4] EV_EFI_BOOT_SERVICES_APPLICATION digest=9c1b... data="\\EFI\\BOOT\\BOOTX64.EFI"
PCR[7] EV_EFI_VARIABLE_DRIVER_CONFIG digest=77d0... data="SecureBoot=1"
PCR[7] EV_SEPARATOR digest=0000... data="Separator"
验证方拿到日志后，从 PCR 初始值开始，逐条执行扩展运算，最后比较复算值与 TPM 报告的 PCR 值。如果一致，说明日志未被篡改；再检查日志中的组件摘要是否在允许列表中，就能判断启动链是否可信。
四、PCR 扩展机制与验证流程
PCR 扩展机制的关键在于“不可逆累积”。TPM 复位后，大多数 PCR 初始值为 0，部分 PCR 在启动早期被固件置为全 1 或特定值。每次扩展都会把旧值与新摘要拼接后再哈希，结果写回同一 PCR。因此，攻击者即使删掉某条日志，也无法让 PCR 回到之前的值；验证方只要发现复算失败，就能判定日志不完整或被篡改。
验证流程通常分为四步：第一，从 TPM 读取指定 PCR 的当前值；第二，获取对应的事件日志；第三，从 PCR 初始值开始，按日志顺序逐条执行扩展运算；第四，比较复算结果与 TPM 报告值，并检查日志中的度量摘要是否匹配预期策略。若两者一致且摘要合法，则启动链可信；若不一致，则说明日志缺失、顺序错误或 PCR 被篡改。
五、典型场景与常见误区
在远程证明场景中，服务器把 PCR 值和事件日志发送给证明服务，证明服务根据基准值数据库判断启动链是否合规。例如，只有 PCR[0] 到 PCR[7] 都匹配预期固件和引导程序摘要，才允许接入敏感网络。在本地场景中，系统可以用 PCR 密封磁盘密钥：只有启动链未变时，TPM 才释放密钥；启动链变化后，PCR 不匹配，密钥无法解封。
常见误区一：把 Measured Boot 当成 Secure Boot 的替代品。实际上前者记录，后者拦截，二者互补。
常见误区二：只看 PCR 值，不看事件日志。PCR 只能说明“有变化”，日志才能说明“变了什么”。
常见误区三：忽略扩展顺序。相同组件以不同顺序度量，PCR 结果不同，验证策略必须固定启动路径。
复盘时，应重点检查：CRTM 是否可信、事件日志是否完整、PCR 索引分配是否符合 TCG 规范、验证方是否使用正确的初始值和哈希算法。只有把度量、日志、PCR 扩展和验证策略作为一个整体来设计，Measured Boot 才能真正为可信启动提供可验证的证据链。