Linux 与 Secure Boot 证书过期危机深度解读

背景

Secure Boot（安全启动）是现代 UEFI 固件的一项安全功能，旨在防止恶意软件在操作系统加载前篡改引导过程。对于启用 Secure Boot 的 Linux 用户而言，无论是有意还是无意，他们的系统都依赖于一项由 Microsoft 提供的密钥来确保引导链的信任。

这一信任链的关键环节在于 shim——这是一个由 Linux 发行版使用的第一阶段 UEFI 引导加载程序。目前，shim 由一个来自 2011 年的 Microsoft 密钥签名，该密钥定于 2024 年 9 月 11 日 过期。一旦过期，Microsoft 将不再使用该密钥对 shim 进行签名，这意味着现有的 Linux 安装介质将无法在启用 Secure Boot 的系统上启动。

虽然 Microsoft 自 2023 年起已提供新的第三方 UEFI 密钥作为替代方案，但许多系统固件数据库中并未安装此新密钥。更糟糕的是，更新固件以包含新密钥可能需要硬件供应商发布系统固件更新，而这一过程并不总是顺利或及时。

核心内容

问题的起源与紧迫性

Fedora 开发者 Mateus Rodrigues Costa 于 7 月 8 日在 Fedora 开发邮件列表中提出了这一担忧。他注意到 Windows 11 当月累积更新中发出的警告，指出部分 Secure Boot 证书将于 2026 年 6 月开始过期。虽然这些证书与用于 shim 的密钥不同，但这提醒了 Linux 社区必须正视证书过期带来的系统性风险。

技术机制与现状

要实现通过 Secure Boot 启动 Linux 内核，UEFI 引导过程要求第一阶段的引导加载程序必须由固件数据库中未过期的密钥签名。这些密钥包含在证书中，证书内含有过期日期和签名等信息。

目前的情况如下：

1. 当前依赖：shim 由 2011 年的 Microsoft 密钥签名，该密钥将于 2024 年 9 月 11 日过期。
2. 过期后果：过期后，除非安装介质包含由 Microsoft 2023 年第三方 UEFI 密钥签名的更新版 shim，否则将无法启动。
3. 已安装系统：大多数已安装的 Linux 发行版通常拥有使用其自身密钥签名的引导加载程序（如 GRUB），这些系统理论上可以继续正常引导，因为信任链的根已转移到发行版自己的密钥上。

硬件与固件的复杂性

问题在于硬件环境的多样性：

• 固件数据库缺失：许多系统的固件数据库中缺少 Microsoft 的新密钥，有些同时拥有新旧密钥，而极少数可能只拥有新密钥（导致无法启动旧介质）。
• 供应商更新：硬件供应商应提供固件更新以添加新密钥。Linux Vendor Firmware Service (LVFS) 及其工具 fwupd 被用来从 Linux 系统更新固件。
• 更新成功率：根据社区报告，密钥交换密钥（KEK）的更新成功率约为 98%，数据库（db）更新成功率约为 99%。然而，即便 1% 的失败率，在数百万用户基数下也是巨大的数字。

已知故障与变通方案

在更新过程中，用户可能遇到 failed to write efivarfs（写入 efivarfs 失败）的错误。这通常与 EFI 变量存储空间碎片化有关。

• 解决方法：重启并清除 BIOS 设置为出厂默认值，可以触发可用 EFI 空间的“去碎片化”，从而提供足够的连续空间来部署更新。BIOS 越旧，遇到此问题的可能性越大。
• 无更新的情况：如果硬件供应商不提供更新，用户可能被迫禁用 Secure Boot 才能安装新系统。

潜在风险与争议

• 平台密钥（PK）丢失：有制造商报告丢失了其平台密钥（PK）的私钥部分。PK 是在硬件制造时烧录的特定于厂商的密钥。更改硬件中的 PK 属于“未探索的水域”，从远程证明（attestation）的角度来看是一个“糟糕的主意”。
• KEK 更新的新颖性：正如 Gerd Hoffman 指出，KEK 更新以前从未发生过，因此 BIOS 供应商可能会出错，导致 KEK 更新失败。
• 安全悖论：Adam Williamson 提出，理论上可以分发使用旧密钥签名的 shim 以兼容旧系统。但 Gerd Hoffman 反驳称，继续使用存在已知安全漏洞的 shim 会使 Secure Boot 的意义大打折扣，因为 Microsoft 不会再用过期密钥签署任何安全补丁。

关键要点

• 关键时间点：Microsoft 用于签名 shim 的 2011 年密钥将于 2024 年 9 月 11 日 过期。
• 直接影响：过期后，使用旧版 shim 的 Linux 安装介质将无法在启用 Secure Boot 的系统上启动。
• 解决方案依赖：系统需要安装 Microsoft 2023 年的新第三方 UEFI 密钥。这通常需要通过 fwupd 和 LVFS 获取硬件供应商的固件更新。
• 更新障碍：
  • 部分老旧 BIOS 因 EFI 变量空间碎片化导致更新失败，可能需要重置 BIOS 设置。
  • 并非所有硬件供应商都会及时提供固件更新。
  • 存在密钥更新失败或供应商丢失私钥等极端情况。
• 已安装系统：大多数已安装并配置好自身密钥链的 Linux 系统可能不受影响，但仍面临无法接收 shim 安全更新的风险。
• 最终建议：对于无法更新固件或面临复杂情况的系统，禁用 Secure Boot 可能是唯一可行的临时方案，但这会降低系统的安全性。

意义与影响

此次事件揭示了 Linux 生态与硬件厂商（尤其是主要关注 Windows 生态的厂商）之间长期存在的结构性张力。Secure Boot 的信任根（包括平台密钥和签名密钥）由 Microsoft 和硬件制造商共同控制，而 Linux 发行版和供应商往往处于被动跟随的地位。

1. 用户体验分化：拥有较新硬件且供应商积极支持的用户可以通过自动化工具（如 fwupd）平滑过渡；而拥有老旧硬件的用户可能面临安装困难或被迫降低安全级别的风险。
2. 安全与维护的权衡：如果为了兼容性而继续使用过期的 shim，将导致系统无法获得针对引导加载程序的安全补丁，从而削弱 Secure Boot 的实际安全价值。
3. 行业协作的必要性：此事凸显了建立更健壮的固件更新机制和更紧密的跨平台协作的重要性。Linux 社区虽然正在尽力应对，但在硬件控制权不在手中的情况下，保持兼容性始终是一场艰难的斗争。

总的来说，虽然绝大多数系统不会因此“丢失”，但这一过程将给发行版维护者、硬件供应商和最终用户带来额外的复杂性和工作负担。