Linux用户可能将面临与安全启动（Secure Boot）相关的又一障碍。由于微软签署的密钥将于9月11日到期，许多发行版依赖该密钥支持这项基于固件的安全功能，届时用户或将受制于原始设备制造商（OEM）的发行策略，系统可能无法获取必要的固件更新。
首先简要了解安全启动的机制。作为统一可扩展固件接口（UEFI）的组成部分，这项功能已取代现代系统中的基本输入输出系统（BIOS）——尽管发烧友和制造商仍习惯称其为BIOS。微软知识库文章将其定义为“由PC行业成员开发的安全标准，用于确保设备仅通过制造商信任的软件启动”。
制造商需确保在出厂时将签名数据库（db）、吊销签名数据库（dbx）和密钥注册密钥库（KEK）写入固件非易失性存储器（NV-RAM），并锁定固件编辑权限——仅允许通过正确密钥签名的更新程序，或由现场用户通过固件菜单操作。制造商还需生成平台密钥（PK），用于签署KEK更新或关闭安全启动。
值得注意的是，这些要求并不排斥非Windows操作系统安装。但由于多数设备预装微软系统，用户需先禁用安全启动才能安装其他系统——这要求用户具备UEFI/BIOS操作知识。核心矛盾在于：替代系统安装后是否允许重新启用安全启动？
操作系统发行商面临三重选择：完全放弃安全启动支持；要求用户自建签名密钥；或利用微软控制的数据库体系实现安全启动。NetBSD和OpenBSD等系统选择第一条路径，而部分Linux发行版与FreeBSD则通过“垫片（shim）”技术，在微软基础设施上构建安全启动支持。
关键转折在于：微软将于9月起停止使用即将过期的密钥签署垫片程序。尽管2023年已提供替代密钥，但多数系统可能未预装该密钥，更糟的是，可能需要硬件厂商发布固件更新——而这种更新存在不确定性。虽然大部分设备不会因此瘫痪，但发行商和用户将面临额外工作量。
解决方案存在两种路径：厂商通过完整固件更新支持新密钥，或仅更新KEK数据库。前者要求厂商为海量产品发布更新以服务小众的非Windows用户；后者作为未经全面验证的机制，设备兼容性存疑。两种方案都可能迫使部分用户自行寻找出路。
颇具讽刺的是，这项存在多重漏洞的安全功能（如波及广泛的BootHole、BlackLotus漏洞，以及MSI、技嘉等厂商的主板专属漏洞），其修复措施甚至不受欢迎——因为某些漏洞曾被用来在缺乏可信平台模块（TPM）2.0的设备上安装Windows 11，用户既不愿困守Windows 10，又不想购置新硬件。
安全启动的初衷值得肯定——增加引导工具包安装难度本应是积极举措。但此次密钥过期事件，不过是加剧用户挫折感的最新案例，最终可能迫使人们继续留守Windows或彻底禁用该功能。当前多数用户选择前者，但随着Windows 10终止支持临近和其他平台崛起，这种局面能否持续？现有形态的安全启动，真的准备好迎接这场变革了吗？
