UEFI 安全启动：从原理到落地

安全启动（Secure Boot）这玩意儿，说白了就是防止你的服务器在启动阶段被“调包”。

我刚开始接触 UEFI 时，觉得它不就是个 BIOS 的替代品嘛。直到有一次，客户的生产环境被植入了一个 bootkit，所有流量都被劫持到钓鱼服务器上……嗯，从那以后，我对 Secure Boot 的态度就彻底变了。

Secure Boot 到底在防什么？

想象一下这个场景：你关掉服务器，去吃了个午饭。回来开机，系统正常启动了，一切看起来都没问题。但事实上，攻击者已经替换了你的 bootloader，加载了一个恶意内核。你的防火墙、IDS、EDR 全成了摆设——因为恶意代码在操作系统启动之前就已经运行了。

Secure Boot 要解决的就是这个问题。它通过数字签名机制，确保从 UEFI 固件到操作系统内核的整个启动链路上，每一个环节都是可信的、未被篡改的。

密钥数据库：PK、KEK、db、dbx

要理解 Secure Boot，必须先搞懂它的密钥体系。我习惯把这四个数据库想象成一个“信任链”的四个环节。

数据库	全称	作用	谁持有
PK	Platform Key	平台所有权的根信任	平台所有者（通常是 OEM 或企业 IT）
KEK	Key Exchange Key	授权更新 db/dbx 的权限	操作系统厂商（如 Microsoft）
db	Signature Database	允许执行的签名/证书白名单	UEFI 固件
dbx	Forbidden Signature Database	禁止执行的签名/证书黑名单	UEFI 固件

我举个例子帮你理解：

• PK 就像你家的房产证。证明这房子是你的，你有权决定谁能进来。
• KEK 就像你给物业公司的授权书。物业可以帮你更新访客名单，但最终决定权还在你手里。
• db 是“白名单”。上面列着你可以信任的人——比如你的家人、朋友。
• dbx 是“黑名单”。上面列着你不欢迎的人——比如那个总偷你快递的邻居。

签名与验证流程

Secure Boot 的验证流程其实不复杂。我画了一张图，你看完就明白了。

具体流程是这样的：

1. 上电自检：UEFI 固件首先验证自己的签名（如果有的话）。
2. 加载 Bootloader：固件读取 bootloader 的签名，用 db 中的证书验证。如果签名有效，放行；如果无效，检查 dbx——如果在黑名单里，直接拒绝。
3. 加载 OS Kernel：Bootloader 用同样的方式验证内核签名。这一步通常由 shim（一个轻量级的 bootloader）完成。
4. 内核接管：内核启动后，Secure Boot 的硬件级验证就结束了。后续的模块加载由内核自己的签名机制（如 IMA、模块签名）负责。

实际部署中的坑

我在帮客户落地 Secure Boot 时，遇到过不少问题。挑几个典型的说说：

• 自定义内核签名：如果你用的是自编译内核，必须用 db 中的证书签名。我曾经见过一个团队忘了这茬，结果所有服务器在更新内核后全部无法启动……嗯，那天的晚餐是泡面。
• 吊销证书：当发现某个证书被泄露时，需要立即将其加入 dbx。但要注意，dbx 更新本身也需要 KEK 签名。所以，KEK 的私钥一定要保管好。
• 兼容性问题：某些老旧的硬件或驱动可能不支持 Secure Boot。我建议先在测试环境验证，再逐步推广到生产。

验证 Secure Boot 状态

部署完成后，怎么确认 Secure Boot 确实生效了？在 Linux 下，可以用以下命令检查：

# 检查 Secure Boot 状态
mokutil --sb-state

# 查看当前加载的密钥
mokutil --list-enrolled

# 查看 db 中的证书
efi-readvar -v db

# 查看 dbx 中的证书
efi-readvar -v dbx

如果输出显示 SecureBoot enabled，恭喜你，配置成功了。