Secure Boot的核心作用是保障启动链完整性，其依赖硬件根信任（RoT）逐级验证签名，覆盖BootROM、固件、引导加载器、内核及initramfs等全部阶段，并通过PK、KEK、db、dbx密钥体系管控信任边界。
Secure Boot 的核心作用就是保障启动链完整性——它不是靠一两个设置开关实现的，而是靠一套从硬件根开始、逐级验证的机制。关键不在于“开了没”，而在于“验证链条是否真实有效、密钥是否受控”。
信任根（RoT）必须硬件固化且不可篡改
整个机制的起点是芯片内部的 BootROM，这段代码出厂即写死，无法被软件修改。它内置一个根公钥（或哈希值），只认这个“公章”。任何后续代码的签名，都必须能被这个公钥正确验签，否则直接终止启动。
- 确保你用的设备芯片支持并启用了硬件级 RoT（如 ARM TrustZone 中的 ROM Code、x86 平台的 CPU 内置 BootROM）
- 不要依赖 BIOS/UEFI 设置里“Secure Boot Enabled”就以为万事大吉——如果 RoT 被绕过（比如通过 JTAG 强制加载、BootROM 漏洞），整个链条就失效了
- 消费级主板和嵌入式 SoC（如高通、NXP、STM32）对 RoT 的实现深度不同，选型时需确认其 RoT 是否符合 PSA 或 Common Criteria 认证要求
逐级签名验证必须覆盖全部启动阶段
从 BootROM 开始，每一段要执行的代码（XBL/ATF → UEFI Firmware → OS Loader → Kernel → Initramfs）都必须带有效签名，并由上一级用对应私钥签名、下一级用对应公钥验证。
- 常见断点：Linux 发行版默认不签名 initramfs 或内核模块；Android 的 AVB（Android Verified Boot）虽独立于 UEFI Secure Boot，但逻辑一致——缺一环，整条链就不可信
- 验证不能只做“存在签名”，还要检查签名证书链是否完整、是否在 db（允许列表）中、是否不在 dbx（吊销列表）中
- 嵌入式场景中，bootloader（如 U-Boot）需配置 CONFIG_CMD_BOOTZ 和 CONFIG_OF_SEPARATE，并启用 FIT image + signature support 才能参与验证
密钥管理决定信任边界是否可控
Secure Boot 不是“开个开关就安全了”，它的安全性高度依赖密钥生命周期管理。四个关键变量 PK、KEK、db、dbx 必须协同工作：
- PK（Platform Key）是最高权限密钥，安装后系统才进入“用户模式”；更换 PK 需物理接触或固件密码，普通用户无法操作
- KEK（Key Exchange Key）用于更新 db/dbx；它本身必须由 PK 签名，才能被固件接受
- db（Signature Database）存允许执行的签名；dbx 存已被吊销的签名（如已知漏洞的旧版 bootloader）
- 生产环境建议使用 Custom 模式，预烧录自有 PK/KEK，并定期轮换 db；避免依赖厂商默认的 Microsoft KEK（易受供应链攻击影响）
启动后仍需延续可信状态
Secure Boot 在 kernel 加载完成时并不“下班”。它为后续机制提供基础信任锚点：
- Linux 可通过 IMA（Integrity Measurement Architecture）结合 TPM，将启动链度量值记录到 PCR 寄存器，实现运行时完整性延续
- Windows Defender System Guard 利用 Secure Boot 建立的初始信任，进一步验证 Early Launch Antivirus（ELAM）驱动签名
- 容器平台（如 Kubernetes with confidential computing）依赖 Secure Boot 保证 host OS 未被篡改，再启动基于 SGX/SEV 的可信执行环境
