Linux Secure Boot 的 2025 麻烦：旧证书到期，真正卡在固件

2025 年 9 月 11 日之后，一些 Linux 安装盘可能会遇到很别扭的一幕：机器开着 Secure Boot，安装介质也没坏，但入口处那张“通行证”过期了。

这张通行证不是 Linux 内核。它是很多发行版用来接上 Secure Boot 信任链的 shim。旧 shim 依赖微软 2011 第三方 UEFI 证书签名，而这张证书快到期了。

别把这件事读成“9 月后 Linux 大面积趴窝”。已安装系统通常不一定立刻无法启动。更集中的风险在新安装、安装介质启动、新 shim，以及那些固件里还没有微软 2023 第三方 UEFI key 的机器。

到期的不是 Linux，是 shim 的通行证

Secure Boot 的逻辑很简单：固件先信任某些证书，再验证启动链上的组件。Linux 发行版通常用 shim 作为第一道桥。shim 通过微软签名进入门内，再接上发行版自己的信任链。

多数用户不会自己管理 Secure Boot key。发行版也不能指望普通人进 BIOS 里导入自签名密钥。所以 shim 这条路很关键，也很脆。

这次卡点在证书轮换。

还有一个灰区：有些固件可能并不严格检查证书时间窗口。

这不是完全没道理。固件时钟可能不准，RTC 会漂，服务器首次安装前时间也可能乱。如果固件真把时间卡得很死，连一些 PCIe 设备 Option ROM 都可能出问题。

但工程不能靠侥幸。某些机器“不查时间”，不能当作解决方案。那只是摸黑过桥，桥还未必在。

真变量在固件更新，不在内核补丁

接下来最该看的，不是 Linux 内核发了什么补丁。核心变量在固件。

新 shim 要用微软 2023 第三方 UEFI key 签名。机器固件如果没有这把新 key，就需要更新。路径可能是厂商固件更新，也可能是通过 KEK/db 更新把新证书写进去。Linux 侧的 LVFS/fwupd 能缓解问题，但不能保证覆盖所有硬件。

Richard Hughes 提到过两个成功率数字：KEK 更新约 98% 成功，db 更新约 99% 成功。

这两个数字看着很稳。放到百万级机器上，1% 就不再是小数点。那是上万台可能失败的设备，是论坛帖子、工单、远程维护、现场返修。

失败也很“固件味”：efivarfs 写入失败，EFI 变量空间碎片化，老 BIOS 更容易出事。有些机器重启或恢复 BIOS 默认值后，变量空间可能被整理出来。但这已经不是“点一下更新”的体验了。

最现实的观察点也很具体：厂商是否推固件，LVFS 覆盖了哪些型号，fwupd 更新失败率是否下降，发行版安装镜像是否给出足够清楚的提示。

真遇到安装介质无法启动，关闭 Secure Boot 可能是最后退路。它不优雅，也不是所有环境都允许。企业里如果有合规或 attestation 要求，关闭 Secure Boot 可能直接不可接受。

这就是麻烦的地方。个人用户还能绕一下。企业和发行版维护者要面对的是规模化失败。

Secure Boot 是安全机制，也是一套入口秩序

我不赞成把这件事简单写成“微软恶意封锁 Linux”。Secure Boot 有真实安全价值。它减少启动链被篡改的机会，也让某些持久化攻击更难做。

问题是，安全机制一旦落到 PC 生态里，就会变成入口秩序。

Linux 这些年能在 Secure Boot 默认开启的机器上顺利安装，很大程度上是在微软和硬件厂商控制的信任根下借道通行。平时看不见这笔账，是因为旧 key 还有效，固件数据库还能凑合，厂商也没有被迫集体补作业。

证书一轮换，账就摆出来了。

“天下熙熙，皆为利来。”这句话放在这里很直白。硬件厂商最在意的是当季 Windows 认证、新机出货和售后成本。老设备上的 Linux Secure Boot 兼容性，天然排在后面。

这和早年 PC 外设、驱动、BIOS 兼容性问题很像。不完全一样，但权力结构相似：标准写在纸面上，最后落地靠厂商实现；厂商实现一参差，用户就替生态付账。

发行版可以准备新 shim。LVFS/fwupd 可以推更新。维护者可以写文档、做检测、加提示。

可最后那一步，经常卡在 BIOS 质量、EFI 变量空间、厂商维护意愿和旧机器生命周期上。

这才是这次证书到期最值得盯的地方：Linux 本身没坏，坏的是它不得不穿过的门禁系统开始换锁。而换锁的人、管门的人、修门的人，并不是同一拨人。

所以接下来不要只问“Linux 会不会启动”。更该问三件事：你的机器有没有 2023 key，厂商会不会给更新，更新失败时有没有可回退路径。

答案如果都含糊，就别等到安装当天再碰运气。