微软Secure Boot密钥九月到期 Linux启动恐遇新挑战​

麻薯滑芝士

电脑开机时那个默默守护启动安全的小功能，下个月可能要给部分用户添堵了。​​问题出在​​微软用来给相关元件签名的数字“钥匙”即将在2025年9月11日光荣退休，过期失效。

要弄懂这事儿为啥让人头疼，得先聊聊Secure Boot究竟干啥的。这玩意儿是现代计算机启动安全的关键，属于统一可扩展固件接口（UEFI）标准的一部分——虽然大伙儿可能还是习惯性地把整个UEFI启动环境叫做“BIOS”。按微软官方知识库的说法，Secure Boot是PC行业联手搞的一套安全规则，它的任务就是在你开机那会儿确保设备只加载厂家认证过的正经软件，拦着恶意软件搞破坏。

具体到机器怎么执行呢？设备出厂前，厂商会在主板固件的特殊存储器（叫非易失性随机存取存储器，NV-RAM）里存好几个安全数据库：签名数据库（db）、吊销签名数据库（dbx）和密钥加注密钥数据库（KEK）。存完以后，厂商就把固件“锁上”，后续改动要么得由专门的平台密钥（PK）签名授权更新，要么就得用户本人亲自到固件设置里手动操作。那个PK嘛，主要就是用来允许更新KEK数据库或者干脆把Secure Boot功能关掉的。

这些设计本身倒没拦着用户装Windows以外的系统，比如Linux。但问题出在，绝大多数电脑出厂预装的是Windows。如果你买了台新电脑想换成Linux，通常第一步得先在UEFI/BIOS设置里手动把Secure Boot关掉——这事儿前提是你得知道怎么操作，而且还愿意动手。关掉之后，更关键的问题来了：装好的新系统，能让用户顺利把Secure Boot再重新打开吗？

这就把操作系统发行版们逼到了十字路口：要么彻底放弃支持Secure Boot（像NetBSD、OpenBSD和一些小众系统走的路子），要么指望用户自己能生成密钥并签名，再要么，就得想办法蹭微软掌控的db、dbx和KEK资源给自己的系统通行证。像Ubuntu、Fedora这些热门Linux发行版和FreeBSD就选了第三条路。它们搞了个小巧的“预引导加载器”，江湖人称“shim”。这个小shim由微软签名确认过，就像一座桥，靠着微软的地盘，为这些系统建立起自己的Secure Boot支持体系。

麻烦来了。根据付费技术媒体LWN的报道（原文是付费内容），微软将在今年9月停止使用那个快要到期的旧密钥为这个shim签名了。报道里写得挺实在：“但是，替代密钥自2023年就有了，问题是它可能还没装到很多用户的电脑上；更棘手的是，这事儿可能还需要设备厂商去发布固件更新，至于厂商肯不肯做、啥时候做，那就真不好说了。目前看起来，大部分电脑还不至于完全启动不了，但这事很可能让发行商和用户都得额外忙活一通。”

报告点明了制造商们能用的两种解决办法：一个是发布一个完整的固件更新包，另一个是单独去更新那个KEK数据库。头一种办法呢，需要制造商乐意为一堆已经不新的产品线专门发布固件更新——目的仅仅是为了照顾一小部分跑非Windows系统的用户能用上Secure Boot；第二种办法（更新KEK）呢，算是一种相对简单的机制，但能不能在五花八门的设备上都奏效，保证不了。所以，不管厂家选哪条路，似乎都有一批用户得自力更生搞定启动问题。

这事儿想起来有点黑色幽默。因为Secure Boot自己也没少出幺蛾子，安全漏洞被公开的也不少：有的影响力贼大（像BootHole、BlackLotus），有的则只针对特定厂家的固件（比如MSI、技嘉）。而且，有时厂商去修复这些固件漏洞，用户还不一定买账。为啥？有些漏洞被人“开发”出来是为了在那些没有可信平台模块（TPM）2.0的老电脑上装Windows 11——毕竟有人想尝新又不乐意花钱买新机子。

Secure Boot的初衷没毛病：它给开机过程加了道安检，让恶意启动工具（bootkits）更难钻空子，这肯定不是坏事。但处理这个即将过期的密钥引起的这场混乱，就像是Secure Boot用户最近一系列不顺心体验里的最新一颗“地雷”，不断消耗着大家的耐心。结果是，要么用户乖乖留在Windows生态里，要么一怒之下彻底关掉Secure Boot了事。目前来看，大多数人还是选了前者。但回头瞅瞅，Windows 10的支持眼瞅着也要到头了，其他操作系统平台也在努力吸引眼球，Secure Boot这个机制还能不能像现在这样把人摁在Windows上？它现在这个存在状态，到底能不能适应未来用户可能更愿意尝试其他系统的趋势？Linux社群和用户恐怕只能先观望了，看看今年9月这个期限之后，有多少人会遇到开机问题，又有多少麻烦在等着解决。