Linux 与 Secure Boot 证书到期

# Linux 与安全启动证书过期 来源：https://lwn.net/Articles/1029767/ > **LWN.net 需要你！** 没有订阅者，LWN 将无法存在。请考虑注册订阅（https://lwn.net/Promo/nst-nag2/subscribe）并帮助 LWN 持续出版。 在系统上启用了安全启动（https://en.wikipedia.org/wiki/UEFI#Secure_Boot）的 Linux 用户，无论有意还是无意，都依赖一把来自微软的密钥，该密钥将于 9 月到期。在此之后，微软将不再使用该密钥来签名 shim（https://github.com/rhboot/shim#shim-a-first-stage-uefi-bootloader）（一级 UEFI 引导加载程序），Linux 发行版用该程序在安全启动下引导内核。但自 2023 年起可用的替换密钥，可能尚未安装在许多系统上；更糟糕的是，它可能需要硬件厂商发布系统固件更新，而这可能发生也可能不发生。看来绝大多数系统不会因此受困，但发行版和用户可能需要额外的工作。 Mateus Rodrigues Costa 于 7 月 8 日在 Fedora devel 邮件列表上提出了该问题（https://lwn.net/ml/all/CAGdXWsG2EM5KhYVjux7Qqj9Zs82HS0LeVQsRhju=Kx8wv_kBwg@mail.gmail.com/）。他注意到了“本月 Windows 11 累积更新”附带的警告，该警告涉及计划从 2026 年 6 月起陆续到期的安全启动证书。这些特定证书与用于 shim 的那把密钥不同，后者到期时间更早。无论如何，证书到期问题是 Linux 世界需要应对的。 情况相当复杂。Daniel P. Berrangé 指出（https://lwn.net/ml/all/[email protected]/）了 Linux 厂商固件服务（LVFS）站点（https://fwupd.org/）上的一个页面（https://fwupd.github.io/libfwupdplugin/uefi-db.html），该页面描述了该问题。LVFS 是 fwupd（https://github.com/fwupd/fwupd?tab=readme-ov-file#fwupd）及其他从 Linux 更新系统固件的工具的大本营。LVFS 和 fwupd 是 2020 年一篇 LWN 文章（https://lwn.net/Articles/832550/）的主题。 该问题涉及多个相互关联的环节。为了安全启动到 Linux 内核，UEFI 引导过程要求一级引导加载程序使用固件数据库中未过期的密钥进行签名。这些密钥包含在证书中，证书还包含其他信息，例如到期日期和签名。证书过期主要只会在安全启动系统上安装新发行版时成为问题；已安装的 shim 将包含发行版特定的密钥，并可作为信任根，使用这些密钥运行其他程序（例如 GRUB）。 目前，shim 使用 2011 年的一把微软密钥签名，该密钥将于 9 月 11 日到期。在此之后，除非安装介质包含使用微软 2023 年用于第三方的 UEFI 密钥（与 Windows 更新中提到的特定密钥不同）签名的新版 shim，否则它将无法引导。任何已安装的发行版都应拥有使用自身密钥签名的引导加载程序，并将继续正常启动。 但存在大量系统的固件数据库中缺少微软的新密钥；有些系统同时拥有新旧密钥；而很可能有些系统只有新密钥，目前甚至无法安全启动 Linux 安装介质。厂商可以提供（并且希望大多数厂商会提供）添加新密钥的固件更新，安装介质也可以使用由新密钥签名的 shim 来创建，但这些更新必须安装到系统上。这正是 LVFS 和 fwupd 发挥作用的地方。 LVFS 是一个各种厂商固件更新的仓库，fwupd 等工具可利用它将所需组件从 Linux 安装到固件中。Berrangé 指出，旧版 fwupd 无法解决所有问题，“但近年来的版本已得到增强，能够处理 Linux 用户需要看到的更新，这应该能减轻最严重的影响”。不过，道路可能仍有些颠簸：“用户应该‘意识到’可能出现麻烦，但希望最令人‘担忧’的部分已由操作系统厂商和维护者处理好了。” LVFS 的创建者和维护者 Richard Hughes 表示同意（https://lwn.net/ml/all/eTTSREqqT0InYduQa-4LKZDofnwn1E37wG6VindAqFk3HYdMNyH_dEgrDbqQU19xivngguIM_H7C4aSoh1ovLX65iCK-_1mRAmwhzlhQMX8=@hughsie.com/），并指出有多种方式可以让用户的系统获得更新的安全启动功能。厂商可能提供完整的固件更新，这将（推测）添加新数据库，包括新的微软密钥。另一条途径是“密钥交换密钥”（KEK）更新，这是一种由微软密钥签名的厂商特定密钥；fwupd 可利用它将新密钥更新到数据库中。但存在一些注意事项： > KEK 更新的成功率达到约 98%，数据库更新成功率达到约 99%——但即使只有 1% 的失败率，乘以数百万用户，也意味着相当多的部署失败——即“写入 efivarfs 失败”的问题。解决部分用户问题的方法是重启并将 BIOS 恢复出厂设置——这会触发可用 efivar 空间的“碎片整理”，从而腾出足够的连续空间来部署更新。BIOS 越旧，越可能遇到此问题。 Hughes 指的是一个已知的新 EFI 变量空间问题（https://github.com/fwupd/fwupd/wiki/LVFS-Triaged-Issue:-dbx-efivarfs-IO-error）。 对于厂商不提供更新的系统，禁用安全启动可能是允许新安装的唯一选择。再过几个月，所有现有的安装映像和介质将无法在安全启动下安装——对于仅拥有新密钥的系统，这可能已经如此。安全启动安装变得复杂了许多。 除此之外，还存在厂商更新出错或出现问题的可能性。Hughes 指出，至少有一家制造商丢失了其平台密钥（PK）的私钥部分，平台密钥是制造时烧录在硬件中的厂商特定密钥。这意味着需要更改硬件中的平台密钥，这是未知领域，并且“从认证角度来看是个糟糕的主意”。此外，正如 Gerd Hoffman 指出的（https://lwn.net/ml/all/sjax5hcevaiaobo5wcfsvu6rqggbkyhd23eb5wpk2n4rkapm4b@tk62rkqukkez/），KEK 更新过程也是全新的：“KEK 更新以前从未发生过，因此 BIOS 厂商很有可能搞砸一些事情，导致 KEK 更新失败。” 该邮件线程中有多份关于各种硬件型号上安全启动证书的报告，以及 KEK 和数据库更新的报告。目前尚不完全清楚的是，固件实现是否真的会强制执行 2011 年密钥上的到期日期。一个使用该密钥构建了功能信任链的正常工作系统，即使在 9 月之后，也可能继续利用由该密钥签名的 shim 运行。然而，任何针对 shim 的更新（例如用于修复安全问题）都无法再使用旧密钥签名——微软不会使用过期的密钥签署任何内容。这可能导致某种“解决方案”，如 Adam Williamson 所说（https://lwn.net/ml/all/[email protected]/）： > 从理论上讲，我们是否也可以选择为这种情况提供旧版 shim？如果整个链条都是旧的，它应该能工作，对吧？当然，我们需要某种启发式方法来确定我们是否在旧版 MS 证书上，并安装旧 shim…… 他说这可能并不真正合理，用户应该直接禁用安全启动。Hoffman 同意（https://lwn.net/ml/all/je2ofqfkajgr25pr33dne6l2cgkksqsofiasrakncpquvbiarp@4pov3pjzveap/）所有这些，但指出了 shim 更新的问题：“继续运行含有已知安全漏洞的 shim 使得启用安全启动变得 [有点] 毫无意义。” 总而言之，Linux 世界似乎在现有条件下尽力而为——正如在大多数只关心 Windows 的厂商硬件问题上常见的那样。鉴于安全启动的信任根密钥（包括平台密钥和签名密钥）都掌握在厂商手中——微软和硬件制造商——要跟上步伐总会有一些困难。由于旧硬件是 Linux 及其发行版明确支持的，而其他厂商早已转向最新的闪亮新品，这显然会导致一些紧张局面。我们只能希望整个过程尽可能顺利。 ---