验证服务器固件升级后安全启动链完整性，需确认硬件信任根激活、固件签名链逐级贯通、运行时度量可审计：RoT须物理固化且PCR[0]稳定；UEFI db中含有效引导器签名，禁用fallback路径；TCG日志中PCR[0..7]哈希链须匹配基准值。
服务器固件升级后，验证硬件底层安全启动链的完整性，不是“检查开关是否打开”，而是确认从CPU上电那一刻起，每一级代码是否真实、可信、未被篡改地完成了签名验证。关键在于三个层次：硬件信任根是否激活、固件层签名链是否完整、运行时度量是否可审计。
确认硬件信任根（RoT）已启用且不可绕过
这是整个链条的起点，必须物理级固化、无法被软件覆盖。
- 进入UEFI设置界面，查看是否有“Intel Boot Guard”“AMD Hardware Verified Boot”或“RoT Configuration”类选项，并确认其状态为Enabled；仅显示“Secure Boot Enabled”不等于RoT生效
- 使用
tpm2_getcap -c properties-fixed命令（Linux下）或tbootinfo工具（Windows下）检查TPM是否处于Active & Owned状态，且PCR[0]值稳定——若每次重启PCR[0]都变化，说明BootROM未参与哈希链构建，RoT未真正介入 - 消费级主板常将RoT设为可选或模拟实现，生产环境应选用通过PSA Level 2或Common Criteria EAL4+认证的服务器平台（如Dell PowerEdge R760、HPE ProLiant DL380 Gen11）
校验固件层签名链是否逐级贯通
UEFI固件升级后，必须确保从固件自身到OS Loader的每一段加载代码都被正确签名并纳入验证范围。
- 在UEFI Shell中执行
dumpdb -d，检查db（允许数据库）中是否包含当前使用的OS引导器签名（如Microsoft Windows Boot Manager或grubx64.efi），同时确认dbx中无已知漏洞版本条目 - 运行
efibootmgr -v（Linux）或bcdedit /enum firmware（Windows），核对当前启动项路径是否指向EFI\Microsoft\Boot\bootmgfw.efi等受签名保护路径，而非EFI\BOOT\bootx64.efi这类fallback路径（后者可能绕过db校验） - 对于ESXi 8.0等虚拟化平台，还需用
esxcli software vib list --signature验证所有VIB驱动是否带PartnerSupported及以上签名等级，CommunitySigned驱动会直接中断Secure Boot流程
验证启动过程是否生成可信度量日志（TCG Log）
即使签名验证通过，也要确认系统是否真实执行了度量——这是防“假验证”的最后一道防线。
- 在操作系统中读取
/sys/firmware/efi/efivars/TCG2FinalEventsLog-*/（Linux）或使用Get-TpmEndorsementKeyInfo+Get-TpmMeasuredBootLog（PowerShell）导出PCR扩展日志 - 用
tpm2_checkquote工具比对PCR[0..7]哈希链与已知基准值；若PCR[7]（Secure Boot策略）为空或与预期不符，说明Secure Boot虽开启但未实际参与验证 - 云环境中（如Azure），该日志会被主机证明服务（Host Attestation Service）自动采集；若升级后首次启动出现“证明失败”，需立即检查TCGLog中是否存在异常跳变或缺失段落
固件升级不是一次写入就结束的动作，而是一次对整条信任链的重置与重建。验证的重点不在“有没有”，而在“是不是真正在用”。漏掉任何一环，攻击者都可能利用签名绕过、fallback路径或PCR伪造，让Secure Boot形同虚设。
