微软签发的 Linux 安全启动证书九月份过期
启用了 安全启动 的 Linux 用户，无论是否知情，都依赖于微软提供的一把密钥，该密钥将于九月过期。此后，微软将不再使用该密钥对 Linux 发行版用于在安全启动模式下加载内核的 shim 第一阶段 UEFI 引导加载程序进行签名。然而，自2023年起可用的替代密钥可能并未安装在许多系统上；更糟糕的是，这可能需要硬件厂商为系统固件发布更新，而此类更新是否会推出尚不确定。似乎绝大多数系统不会因此受影响，但这可能需要发行版提供商和用户额外付出努力。
Mateus Rodrigues Costa 于7月8日在 Fedora 开发邮件列表中提出了这一问题。他注意到随“本月Windows 11累积更新”附带的警告信息，该信息提及计划于2026年6月开始过期的安全启动证书。这些特定证书与用于shim的证书不同，后者过期时间要早得多。无论如何，证书过期问题是Linux世界需要解决的课题。
情况相当复杂。丹尼尔·P·贝朗热(Daniel P. Berrangé)指向了Linux供应商固件服务(LVFS)网站上的页面 (https://fwupd.org/) 上的一个页面，该页面对此进行了描述。LVFS 是 fwupd 及其他用于从 Linux 系统更新固件的工具的归属地。LVFS 和 fwupd 是 2020 年 LWN 文章的主题。
该问题涉及多个复杂环节。要通过安全启动进入 Linux 内核，UEFI 启动过程要求第一阶段引导加载程序使用固件数据库中未过期的密钥进行签名。这些密钥包含在证书中，证书还包含其他信息，如过期日期和签名。证书过期主要在安全启动系统上安装新发行版时才会成为问题；安装的 shim 将包含发行版特定的密钥，并可作为信任根，使用这些密钥运行其他程序(如 GRUB)。
目前，shim 使用 2011 年 Microsoft 密钥签名，该密钥将于 9 月 11 日过期。此后，除非安装介质包含使用 Microsoft 2023 UEFI 密钥(针对第三方，与 Windows 更新中提到的特定密钥不同)签名的更新版 shim，否则将无法启动。已安装的发行版应使用其自有密钥签名的引导加载程序，该引导加载程序将继续正常启动。
但目前市面上存在大量固件数据库中缺少微软新密钥的系统，部分系统同时包含旧密钥和新密钥，而可能还有部分系统仅包含新密钥，导致当前无法对 Linux 安装介质进行安全启动验证。厂商可以(且希望大多数会)提供添加新密钥的固件更新，安装介质也可通过该密钥签名的补丁进行创建，但这些更新必须安装到系统中。这就是LVFS和fwupd发挥作用的地方。
LVFS是一个包含各种厂商固件更新的仓库，fwupd和其他工具可以利用它将所需的更新安装到固件中。Berrangé指出，较早版本的fwupd无法解决所有问题，“但最近的版本已得到增强，能够处理Linux用户所需的更新，这应能缓解最严重的影响”。然而，仍可能存在一些波折：“用户应’意识到’潜在的麻烦，但希望最严重的’担忧’部分由操作系统供应商和维护者处理。”
LVFS的创建者和维护者理查德·休斯表示同意，指出人们的系统可以通过多种方式获得更新的 Secure Boot 功能。供应商可能会提供完整的固件更新，这将(推测)添加新的数据库，包括新的微软密钥。另一种途径是“密钥交换密钥”(KEK)更新，这是由微软密钥签名的厂商专用密钥；它可用于通过fwupd更新数据库以添加新密钥。但需注意以下几点：
KEK 更新的成功率约为 98%，数据库更新的成功率约为 99%——但即使是 1% 的失败率乘以数百万用户，也会导致相当多的部署失败——这就是所谓的“无法写入 efivarfs”问题。对于部分用户，解决方法是重启并恢复 BIOS 至出厂默认设置——此操作会触发可用 efivar 空间的“碎片整理”，确保有足够的连续空间部署更新。BIOS 版本越旧，遇到此问题的概率越高。
Hughes提到的是一個已知的新EFI變數空間問題。
对于供应商不提供更新的系统，禁用安全启动可能是允许新安装的唯一选项。在短短几个月内，所有现有安装镜像和介质都将无法在启用安全启动的系统上安装——对于仅使用新密钥的系统，这可能已经成为现实。安全启动安装变得更加复杂。
除此之外，还有供应商更新中可能出现的错误或问题。休斯指出，至少有一家制造商已失去对其平台密钥(PK)私有部分的访问权限，该密钥是制造时烧录到硬件中的供应商专用密钥。这意味着硬件中的平台密钥需要更改，而这属于未探索的领域，且“从验证角度来看是个糟糕的主意”。此外，正如格德·霍夫曼(Gerd Hoffman)指出的，KEK更新过程也是全新的： “此前从未发生过KEK更新，因此存在BIOS厂商操作失误导致KEK更新失败的风险。”
该讨论线程包含多份关于不同硬件型号安全启动证书的报告，以及关于KEK和数据库更新的报告。目前尚不完全明确的是，固件实现是否会实际强制执行 2011 年密钥的过期日期。基于该密钥的有效信任链的系统可能在 9 月之后仍能与使用该密钥签名的补丁继续工作。然而，任何补丁更新(例如为解决安全问题)都无法使用旧密钥签名——微软不会使用过期密钥签名任何内容。这可能导致某种“解决方案”，正如亚当·威廉姆森所说：
理论上，我们是否也可以为这种情况提供一个旧的补丁？如果整个证书链都是旧的，应该可以正常工作，对吧？当然，我们需要一些启发式方法来判断是否使用了旧的微软证书，并安装旧的补丁……
他表示这可能并不合理，用户应该直接禁用安全启动。霍夫曼表示同意上述观点，但指出了补丁更新的问题： “继续运行存在已知安全漏洞的 Shim，使得开启安全启动变得 [某种程度上] 毫无意义”。
总的来说，Linux 社区在当前情况下已尽最大努力——这在面对主要关注 Windows 的硬件厂商时，往往是常见的局面。由于安全启动的信任根密钥(包括平台密钥和签名密钥)均由厂商(微软和硬件制造商)控制，因此保持同步始终会面临一定挑战。由于 Linux 和发行版明确支持旧硬件，而其他厂商早已转向最新硬件，这显然会引发一些矛盾。只能希望这一过程能尽可能顺畅。
这不仅仅是Linux的问题——2026年，用于签名Windows的证书也将受到影响。
https://support.microsoft.com/en-us/topic/windows-secure-boo…
https://techcommunity.microsoft.com/blog/windows-itpro-blog/…
实际上，为这些证书设置任何有效期似乎都是个错误。它唯一可能防范的是签名密钥被泄露，但如果需要等待15年才能让泄露的密钥失效，那它就没什么用了！
别担心，微软的替代证书有效期至2038年(比32位Unix时间滚动后几个月)。
错误不在于证书没有设置有效期，而在于信任硬件厂商在主板和笔记本电脑出厂后还能进行基本的固件维护。
理论上，KEK更新可以解决有效期问题，就像在任何正常操作系统上更新CA包一样。
实际上，大多数UEFI固件都写得一团糟，无人维护，且大多未经测试。
这让我想到一个更大的问题，UEFI本身就是垃圾，过于复杂、臃肿，难以实现各种功能模块。
我认为系统固件应做到绝对必要的最小化。找到处理器可执行的数据块，就像BIOS时代那样，只需加载前512字节并开始运行。任何其他功能，如硬件配置、电源管理等，都应交给操作系统处理。
手机和许多嵌入式系统都采用这种极简系统固件，结果是一团糟，基本上迫使你为每个设备发布专用软件版本，而EFI本可以为你抽象出所有硬件特定的细节，从而支持多种设备的通用系统软件镜像。
因此，许多此类设备存在漏洞、不安全且一旦出厂后就不再更新，或更新很快被放弃。
这不现实。太多内容依赖于主板，指望供应商将这些内容提交上游(甚至披露文档)永远行不通。我认为应该做的是交换权限级别，使开机后的固件服务在操作系统下运行，而不是在其之上。ACPI，尽管有其缺点，已经非常接近了。另一方面，RISC-V犯了同样的错误，在他们的监督器规范中以其他名称引入了SMM，并添加了他们自己的秘密配方，强制将该死的定时器接口通过SBI( seriously, WHY? 高定时器延迟在x86架构上一直是个问题，自Win95以来就需要各种奇怪的 trick 来解决)。
这里真正的误区是认为BIOS只是加载512字节并开始执行。事实上，在UEFI出现之前，BIOS就已经在做大量工作来配置硬件并为操作系统提供信息。
UEFI出现前BIOS所做的所有“即插即用”(PnP)和“扩展系统控制”(ESCD)功能，都是为了支持DOS或因DOS而存在。APM利用系统中断请求(SMI)实现风扇和电源控制，以便DOS能在90年代的笔记本电脑上运行。这一系列复杂机制最终演变为ACPI和UEFI的噩梦。
固件真正需要做的只有三件事：A) 初始化内存，B) 初始化显示器或串口以进行启动通信，C) 加载操作系统。现代固件做的其他任何事情都应作为由操作系统驱动程序控制的普通设备，而无需ACPI/UEFI层。
第三点：当然，如果固件能提供一种可靠识别平台并提供未连接到可发现总线(如总线控制器本身)的设备数据的方式，那会非常方便，但即使这样也不是必需的。Linux允许你在内核中构建设备树。
> Linux允许你在内核中构建设备树。
对于普通用户来说，如果遇到任何稍微不寻常的情况，这绝对是一场噩梦。
UEFI只是将厂商和操作系统制造商原本就在做的事情进行了标准化。即使在BIOS时代，固件就已经在做PXE启动，以及修改Windows内存以在启动时注入二进制文件，从而将他们的驱动程序/垃圾软件注入到干净的安装中。
如果你知道在哪里寻找，你可以为许多主板刷写各种替代固件，但这些固件通常最终会重新实现 UEFI 所做的一切，以使操作系统能够正常工作。一些固件发行版甚至使用完整的 Linux 内核作为 UEFI 的替代品。
只要 UEFI 终于解决了双启动问题，我随时都会选择 UEFI 而不是 BIOS。
> 修改Windows的内存，在启动时注入二进制文件，以将驱动程序/垃圾软件注入干净的安装中。
等等，什么？这个东西至少有礼貌地检查过你是否确实正在启动Windows，还是说如果你尝试使用主板(!)与任何其他操作系统，就会随机崩溃？
这些东西似乎离供应链攻击只有一步之遥。
https://view.officeapps.live.com/op/view.aspx?src=https%3A%2…
更准确地说，微软会从内存中的特定位置读取并执行二进制文件，这使得公司能够保持持久性/确保其驱动程序始终安装/ …
您还需要协助操作系统进行硬件检测。即使是较旧的BIOS系统也支持ACPI等标准。
EFI是英特尔在Itanium架构下重新定义IBM PC的一部分。我认为这是该项目中为数不多的幸存遗产之一。
没有基本的固件维护工作需要做。固件应该被妥善设计，不可更改，至今有时仍以物理方式以1和0的形式存储。将保质期刻在石头上是没有意义的。
固件需要维护，因为除非你在为航空航天行业工作，否则你无法通过数学证明你的固件没有漏洞。最终有人需要安装更新。
编写良好的固件无需更新即可使密钥数据库保持最新。然而，部分厂商操作失误，现在需要固件更新，而另一些厂商则直接将新密钥存储在NVRAM中。
更不用说固件更新往往需要支持新CPU等功能。不可变固件意味着你的系统无法改进或扩展以支持新硬件，而我可不希望为了支持新CPU而不得不购买新主板。
你不应该需要新的专有软件来支持新硬件，这根本就是错误的。他们只是将免费应用程序捆绑到硬件中而已。
“新CPU需要新软件”不应成为让CPU成为独立计算机的借口，而你所购买的真实CPU只是其中一个功能。这从根本上就是错误的。
这就是现实。这种情况经常发生。
现代计算机是组件的分布式系统。每个组件都有自己的CPU和在固件中运行的操作系统。它们通过系统总线进行通信。
你似乎在讨论硬件控制器与CPU的区别。
这些仍然是处理器，就像CPU一样，只是速度较慢。
不，真正的错误是将信任根放置在用户之外的任何地方。
用户可以将自己的密钥加载到安全启动存储中，并使用这些密钥，而无需预装的证书颁发机构的干预。
这个问题只影响那些不想成为信任根的人。
从微软的角度来看，这不是错误。这就是重点！毕竟，用户是一个潜在的盗版者。
到期日有何用途？可能我遗漏了什么，但我实在看不到除了不必要的复杂性之外的其他用途，而这正是错误所在。(UEFI/固件生态系统中确实存在其他问题，但这无法为到期日辩解)
我不知道这是不是安全启动设计者采用这种设计的原因，但到期日期可以使CRL更小，至少在理论上是这样。如果一个被撤销的证书到期，你不需要将其添加到CRL中，因为信任会自动失效。通过定期轮换根密钥，你还可以使易受攻击的引导加载程序的撤销列表更小，因为你可以移除任何易受攻击的引导加载程序，当其签名密钥到期时。
考虑到这类主板上NVRAM存储的成本控制，能够缩小CRL的大小确实能带来差异。
UEFI中与CRL对应的是“禁止签名数据库”(或DBX)——但据我所见，它仅包含658条记录(来源似乎是https://github.com/microsoft/secureboot_objects/blob/main/Pr… )
另一个潜在用途是促进对过时加密函数/协议/哈希套件等的受控淘汰。
这与10年轮换周期相当契合，且从长期来看，其价值可能高于单纯缩小DBX大小。
嗯，我猜这是其中一点。但15年累积的已撤销证书列表相当庞大，不确定这样做能带来多少实际收益。
闲聊一下——好奇是否存在可用于已撤销证书列表的完美哈希结构。
作为一名 Linux 用户，我感到震惊——震惊！——听到消费类硬件厂商为了追求短期利益而放弃维护，这让我感到震惊。
我感觉/猜测，证书过期更多是一种遵循传统的做法。TLS 证书会过期，这是安全功能的一部分，那么为什么 Secure Boot 证书不能过期呢？
当然，这也会赋予根证书颁发机构巨大的权力，从微软的角度来看，这倒是个好消息。
然而，如果微软真的重视安全，他们不应允许系统上安装的应用程序执行未经用户批准的操作(如安装加密所有数据的病毒)，这实际上可以提升用户体验和安全性。但有了安全启动，至少可以确保Windows内核未被篡改，从而正确运行病毒 🙂
> 似乎为这些证书设置任何过期日期都是一个错误。
尤其是在攻击者控制系统时钟的场景下，大多数相关攻击都会发生。
这真的是一个错误吗？还是微软只是不再关心计算机是否按预期运行。
这绝不是第一个证据……
从悲观的角度看，人们原本期望计算机会在证书过期前被更换。
灾难恢复计划一定很有趣——“从商店A取一台新机器，使用存储在盒子B中的Windows光盘，然后……”
我们不得不通过微软签名才能让操作系统在第三方电脑上运行，而微软竟能如此轻松地赢得这场博弈，因为它从未受到过 serious 挑战，这简直疯狂。
如果从本质上看，这更像是‘诚实的萨蒂亚证书授权机构’。
微软证明了他们能够半熟练地运行PKI。就这样。
如果Linux社区早些时候挺身而出，而不是像孩子一样把安全启动视为计算界的反基督，故事可能会不同。但他们没有。我们只有shim，因为红帽的一些人有足够的常识来合作。
安全启动是计算领域的邪恶存在，Linux社区完全有理由反对它。以及其他一堆“可信计算”垃圾。
没错，这为我们不再拥有自己的手机打开了大门，很快甚至连浏览器本身也不例外。
能详细说明吗？
我很好奇我的机器是否被早期启动阶段的“元hypervisor”入侵。
安全启动和可信计算的承诺是无后门启动。
在你看来，这有什么邪恶和垃圾的地方？
谁控制着该死的证书？
“我的电脑被早期启动阶段的超visor后门入侵”这种情况几乎从未发生过。这几乎完全存在于信息安全白痴的脑海中。
“我的新设备出厂时预装了供应商选定的启动证书，这些证书无法更改、无法覆盖，并且控制着我可以安装到自己设备上的软件”这种情况在每一部智能手机、游戏主机、汽车，甚至某些个人电脑上都存在。
“可信计算”从一开始就是为了确保用户实际上并不真正拥有自己的设备。这是真正的、可触摸的攻击向量——而此次攻击的目标是用户的自由与选择权。
> 谁控制着这些该死的证书？
证书颁发机构，就像SSL证书一样。那么SSL也是为了剥夺互联网自由而设计的邪恶技术吗？
> 供应商选定的启动证书无法更改
这是谎言。某些驱动程序使用特定密钥签名，且仅在该密钥安装时才能使用，这合乎逻辑。SSL也是如此——若从设备中移除预装的CA证书，HTTPS网站将无法访问。然而，你完全可以向系统添加自有密钥并用其签名软件。
> 这种情况在其他智能手机、游戏主机、汽车甚至部分电脑上也存在
你多久会尝试在智能手机、主机或汽车上安装自定义驱动程序？为什么这些设备会出现安全启动问题？
> 此次攻击的目标是用户的自由与选择。
这正是用户拥有自由与选择权的原因——他们可以直接禁用安全启动。
以iPhone或Switch为例。然后在上面禁用安全启动。祝你好运。
苹果或任天堂之所以不遗余力地让这变得不可能，并不是为了用户安全。而是为了他们30%的App Store分成。
在现实世界中，安全启动的存在是为了“保护”供应商的收入来源——而个人电脑是唯一一种用户可以禁用它的设备。大多数时候。
智能手机领域发生的事情足以让人将PC上的安全启动视为一种持续的威胁。目前仍存在合法方式来禁用或调整安全启动的唯一原因，是大多数PC制造商尚未建立自己的应用商店。
自由与安全应视具体情况而定。如果我没有选择权，我就不自由，而安全启动就是一种选择。拥有它在一定程度上提升了我的自由和安全。我希望同时拥有解锁和锁定的硬件，以满足不同需求。
安全启动几乎从未是选择。它只是硬件供应商强加给你的东西，无论你喜欢与否。
这是我经常做出的选择。我昨晚刚在其中一台电脑上禁用了它。今天我可能会重新启用它。切换它很简单。
现在在你的智能手机上做同样的事情。然后在你的智能手表上。然后在你的游戏主机上。
在PC上，安全启动被视为“一个选择”是例外，而非常态。在几乎所有其他设备上，厂商都会强行启用启动过程，并告诉你“这是为了让你更安全”，如果你抱怨的话。
安全启动正在革新设备安全。
> 这是他们30%应用商店分成带来的“安全”。
> 大多数PC制造商没有自己的应用商店。
我觉得你误解了安全启动的作用。它与用户空间应用或应用侧载完全无关。确实，你无法轻松地在苹果设备上侧载应用——但这与安全启动毫无关系，其他设备上的用户空间应用也与它无关。
> SSL 也是旨在剥夺互联网自由的邪恶技术吗？
如果没有 Let’s Encrypt，答案是肯定的！
如果注册密钥非常简单，安全启动就不会成为问题。给我一个大提示，比如：
“你尝试运行的操作系统是由未知密钥签名的
sha256:whateverthefuck
如果您不是在运行安装程序，您很可能正在遭受攻击，不应继续。
如果您正在运行安装程序，请使用操作系统供应商提供的密钥验证该密钥。
继续？(将密钥添加为受信任)
是 否”
我运行双子座服务器(协议，而不是大语言模型(LLM))，但不再运行网络服务器，至少一半的原因是它使用了与 SSH 类似的“首次使用信任”机制，而不是要求所有复杂的 CA。
我并不是说所有网络都应该在保持其他方面不变的情况下转换到这种机制，但在某些情况下，只要用户了解风险，使用更简单的机制还是不错的。
阿门。这就是它应该的工作方式。
> 你多久会尝试在智能手机、游戏机或汽车上安装自定义驱动程序？为什么这些设备会出现安全启动问题？
大多数智能手机上没有蓬勃发展的第三方操作系统社区的唯一原因就是安全启动阻止了这一点。而且，用户没有自由和选择权来禁用它(除了极少数型号，制造商慷慨地允许用户按自己意愿使用设备)。
<< 这就是为什么用户有自由和选择权来禁用安全启动？
我可能记错了，但安全启动的初始计划并不开放。正是由于引发的争议，才使其成为可选项。
<< 你在智能手机、游戏主机或汽车上安装自定义驱动程序的频率有多高？为什么这些设备会出现安全启动问题？
这重要吗？这是我的问题吗？如果是，那它就应该是我关心的问题。但这就是可信计算和近期趋势的全部问题所在。企业成为运营商，用户被降级为消费者。
> 我可能记错了，但最初的Secure Boot计划并不那么开放。正是由于引发的争议，才使得它成为了一个可选项。
还有对反垄断执法的担忧。我们仍然能够禁用安全启动或注册自己的密钥，唯一的原因是替代的PC操作系统已经存在并且足够流行，试图限制PC只能运行微软批准的操作系统将引发严重的反垄断担忧。
但我们仍然面临严重风险。微软仍然对PC制造商有足够的影响力来决定他们的硬件要求，只要他们不再害怕反垄断，就可以要求他们不再允许覆盖。他们已经通过“安全核心PC”(https://download.lenovo.com/pccbbs/mobiles_pdf/Enable_Secure…)让事情变得更加困难。
“ . 但这些不仅是违法的，就像调试器一样——如果你有调试器，你无法在不知道计算机根密码的情况下安装它。而FBI或微软支持也不会告诉你这一点。”
这就是可信启动，正如1997年所预测的那样。它终将到来。
对于那些不知道这段引文出处的人：https://www.gnu.org/philosophy/right-to-read.en.html，该文章首次发表于1997年。
> 这就是为什么用户有自由和选择权可以直接禁用安全启动？
在某些x86硬件中，禁用安全启动的选项无法正常工作。这也是Shim存在的初衷之一——它允许在安全启动启用时，在机器所有者同意的情况下启动未签名代码。
我有一台这样的Windows 8笔记本电脑。不仅如此，它还拒绝了Shim。我从未成功在上面安装过Linux。
奇怪的是，后来我不得不一直关闭安全启动选项，因为越来越多的游戏开始与nVidia GPU出现兼容性问题。有一款我忘了名字的等轴投影风格RPG游戏，如果启用安全启动就会直接崩溃。
> 证书颁发机构，就像SSL的情况一样。SSL也是为了剥夺互联网自由而设计的邪恶技术吗？
是的，网络PKI中信任的委托方式同样荒谬至极。从一开始就应该采用类似DANE的机制。
[1] DANE：基于DNS的命名实体认证
> 谁控制着该死的证书？
你可以？删除默认的(即Windows证书)并导入自己的。
我认为这仅在x86 EFI机器上是必要的，因为一些旧的反垄断裁决。前提是固件供应商正确实现了它。
例如在ARM上，硬件(包括一些搭载ARM版本Windows的硬件)无需提供添加自定义证书或删除现有证书的选项，因此据我所知在大多数情况下这是不可能的。
我认为在Tianocore EDK2 ARM UEFI中也可以实现相同功能
但确实，许多ARM主板并未采用开源UEFI固件
哈哈，你显然从未听说过联想的恶意软件事故。
这些问题正是你所称的“信息安全白痴”们曾警告过的。
我读过。
> 我很想知道我的机器是否在早期启动阶段被“元超visor”入侵。
从你控制的只读介质启动，或从可信来源设置网络启动——无论如何你都必须信任固件。安全启动本身毫无意义。
> 你必须信任固件
如果它是具有可重复构建的自由开源软件(FLOSS)，你的信任可以最小化，因为社区验证一直在进行。此外，你的建议使用和设置起来相当不方便和繁琐。
考虑使用 Heads 搭配 TPM 和 Librem Key 来检测启动阶段的潜在安全漏洞。它不听命于微软，而是听命于你。
使用 Heads 时，固件会自行测量并向 TPM 发送结果。如果攻击者刷入一个修改过的固件，该固件只是谎报测量结果，整个安全系统将被绕过。
这并不正确：
https://forum.qubes-os.org/t/discussion-on-purism/2627/187
https://forum.qubes-os.org/t/discussion-on-purism/2627/177
那还是安全启动，对吧？只是不是UEFI而是自研的？
我没意见。我认为GP是完全拒绝这个想法。
说到另一个显而易见的问题：我后来意识到ME是一个运行BSD的x468。这个小东西对你的机器有完全访问权限。
如果信任和安全是目标，我们找到值得信赖的硬件将面临艰巨挑战。
我的Librem 15上已禁用并中和了ME：https://puri.sm/learn/intel-me/
现在来搞定Systemd…
尽管你可能觉得我幼稚，但我不想在安装软件到自己的硬件前，要求微软为我签发证书。
无论这是每次安装都要求，还是仅限于每台硬件一次，我都不想在安装软件时向第三方寻求许可。我希望这完全可以在离线状态下实现。
此外，保留微软的CA证书会大大削弱SecureBoot带来的任何安全保障。
> 此外，保留微软的CA会大大降低我从SecureBoot获得的安全性。
难道不能直接从UEFI中移除所有CA，然后通过大多数主板厂商导入自己的CA吗？
是的，我的系统就是这样设置的。我也很欣赏每个固件都允许我恢复原始密钥，以防万一，而无需手动备份——但它们对安全启动无效。
也许这并不是一个很好的观点，但RedHat/LKF等公司显然可以运行一个“半合格”的PKI，而且可能应该这样做。但这样做将允许PC厂商在Windows和Linux之间干净地划分机器(+$$)，因此或许最好的选择是低调行事，使用微软的基础设施来实现这一点。
很容易想象像戴尔这样的公司会向你出售预装Ubuntu但没有Windows签名密钥的系统，这样你就无法在启用了安全启动的未修改系统上运行Windows(反之亦然)。
这未必出于恶意，但至少是能力不足。
同样，微软对Shim进行签名也意味着，任何安装了签名Shim的Linux系统都可以安装在支持Windows的任何系统上，而如果红帽拥有自己100%专业、顶尖的PKI，那么今天销售的大部分系统都无法运行未经修改的Linux，因为制造商不会费心去支持。
这其实并不准确。
微软使用三个独立的CA来签名Windows启动加载器、第三方启动加载器(包括Linux启动加载器)以及UEFI选项ROM。
从理论上讲，制造商无需将这三个CA都设置为受信任。但这样做毫无商业意义——为何要为了锁定用户而专门推出两个不同的硬件SKU？一旦消息传开，没人会购买该制造商的产品。
当然会，如果这样能让他们赚钱的话。例如联想已经为专业版ThinkPad(带“认证”Linux支持)和消费级产品线推出了不同型号。戴尔也是如此。PC厂商已经拥有9000个SKU，多几个又何妨？
这让我想起当年一些Windows 9x系统厂商在BIOS中添加了阻止安装NT/2000的机制。必须采用企业版才能实现。
参考：https://bugzilla.mozilla.org/show_bug.cgi?id=647959
如果Linux用户“挺身而出”并要求自己的独立PKI，情况不会有任何不同，除了每个预装Windows的系统都会被锁定在Windows上。双系统启动将不复存在。
我的意思是，你的陈述自相矛盾。Linux用户从未要求过签名等功能。因此，如果行业听从了Linux用户的要求，就不会有签名机制。我们并不生活在那个世界。
有些厂商没有启用安全启动。例如System76。如果你想启用自己的安全启动，可以这样做[1], 不过有些功能可能无法正常工作，比如检查GPU固件签名，因为这些签名仅由微软签发(具体问题取决于微软在你的系统中深度集成程度，例如“在某些设备上，移除其中任何一个密钥都可能导致所有视频输出失效”)
[1] https://wiki.gentoo.org/wiki/Secure_Boot
这毫无意义。
微软使用独立的CA(即独立的根证书)来签名Windows和Linux引导加载程序。
这两个CA都必须被信任。理论上，它们也可以被单独撤销。
没有理由认为“第三方”CA不能由红帽运行。微软这样做只是出于方便。
> 如果Linux阵营早些时候能积极应对，而不是像孩子一样胡闹
这种受害者指责很快就会让人厌烦，仿佛Linux生态系统对PC制造商有任何影响力……
> 仿佛Linux生态系统对PC制造商有任何影响力……
Linux在服务器市场占有63%的份额，而安全启动和整个信任链在这里至关重要。当然他们有影响力。
你认为在保护银行服务器安全的背景下，安全启动比保护某台色情网站使用的廉价笔记本电脑更重要吗？
或者我们有官方机构来做这件事，并强制供应商添加其他受信任方的证书。不仅微软能做到这一点。微软在签名方面也已经出现了问题。
安全启动仍然是邪恶的，但我们不得不与之共存。
问题不在于微软是签名方，而在于我们无法信任系统制造商更新系统，甚至无法确保系统能够正确更新。
建立一个公共签名机构(或至少是一个非营利机构)是个好主意，但这并不能解决我们真正担忧的核心问题。
基本上，每台x64计算机都设计为能够运行Windows。因此微软必须参与其中，我想其他有实力的公司也不愿承担这个负担。
据我所知，大多数UEFI固件仍可禁用安全启动，从而启动任何你喜欢(或不喜欢)的系统(如果攻击者篡改了你的系统)。
安全启动属于一类安全措施，虽然在理论上确实能带来一定好处，但在实际应用中却远未达到为系统用户提供任何实质性益处的程度。其引入主要是作为更广泛(可能部分已废弃且在移动x86领域失败)的策略的一部分，旨在锁定个人电脑，从而使微软应用商店及通过该商店购买的应用程序对终端用户而言更加安全。其次，在我看来，对于运行x86的手机和平板电脑而言，安全启动确实能提供更好的安全保障，但在此类设备上，“应用商店”的特性更为明显。
“攻击者篡改你的系统”这种情况至少不会以你想象的方式发生，或者说它根本无法抵御有意义的攻击。
安全启动(Secure Boot)设计旨在缓解哪些类型的攻击？是“恶意女仆攻击”(Evil Maid Attack)？还是意外以
sudo权限运行的程序确实会破坏整个启动过程并注入根套件等？还是其他情况？> 安全启动设计旨在缓解哪些类型的攻击？
引导扇区病毒，或其现代等价物。基本上，任何在杀毒软件启动前注入引导链的恶意程序；在此之后，杀毒软件应能阻止任何恶意软件。也就是说，他们希望防止恶意软件通过在杀毒软件启动前加载来躲避杀毒软件。
另一个例子：一个自定义内核构建或内核模块，它在内核级别后门你的系统或窃取数据。安全启动提供了从固件制造商一直到你个别内核模块的信任链的机会。
固件验证shim。shim验证引导加载程序。引导加载程序验证内核。内核验证内核模块。
一旦建立信任链，还可以添加其他因素：使用密钥加密磁盘，将密钥封存在 TPM 中，并通过验证固件和引导加载程序来锁定该密钥。系统启动时，这些组件会被测量并写入 PCR，如果组合正确，密钥将被释放，磁盘可自动解密。如果有人使用不同的固件或引导加载程序启动系统，TPM 将不会释放密钥，您的磁盘无法被解密，除非有人拥有密码短语、恢复密钥等。
没有安全启动，您无法信任这些组件不会向 PCR 报告伪造的测量值，欺骗 TPM，并通过从受损的 USB 驱动器启动来获取解密磁盘的密钥。当然，这意味着您可以仅使用手动输入的密码对磁盘进行加密，但对于许多用户(遗憾的是)而言，这过于复杂，他们会选择完全不使用磁盘加密。
以TouchID和FaceID为例，它们被视为替代PIN码或密码解锁iPhone的方案，但实际上它们的初衷是替代完全不锁屏的操作——通过让设备安全机制足够透明，促使所有人都使用它。若缺乏从固件到内核的可信链，这种方案便无法实现。
主要是恶意女仆和根套件。这也是信任链的一部分，它可以在无需输入密码的情况下解锁加密磁盘。
在Windows系统中，安全启动在应对根套件方面效果不错。MBR根套件易于编写，但UEFI根套件需要修改UEFI固件或利用启动加载程序本身，这两种方法都复杂得多。如果恶意软件使用Linux shim，TPM会检测到并拒绝提供Bitlocker密钥，因此你的电脑无法启动，除非你去IT部门申请恢复密钥(这应引发进一步调查)。
这就是问题所在——“恶意女仆”威胁场景主要针对政府行为者，即使对组织而言也是如此。您的示例主要展示了组织如何保护自有设备免受无特权用户的随意滥用。这无法抵御任何严重攻击，仅能防范通常无需担忧的风险。
> 或者，意外以 `sudo` 权限运行的程序确实可能破坏整个启动过程并注入根套件等？
更现实的场景是利用权限提升漏洞。此类漏洞在Windows和Linux系统中都曾大量存在且未来仍会出现。
任何让你无法访问自己电脑的情况，最多只能算是可用性故障，但更常见的是迫使你使用已被入侵的系统软件。
微软本不必参与其中。问题在于，做好这件事很难，不是那种“虽然一开始很难搞清楚，但一旦搞清楚了就一切正常”的难，而是那种“每个用户现在都必须记住一个无法记住的密钥，否则就会被锁在系统之外”的难，基本上是所有支持噩梦的根源。因此，微软选择了最简单(或许现实中唯一)的解决方式。他们说：“我们不会让最终用户拥有自己的密钥，我们将拥有这些密钥。”
说实话，我希望他们(这里指的是设计这个破系统的人)能做好这件事。在首次启动时，你会设置一些密钥，现在你就是自己的信任根，当你想让微软管理你的系统时，这完全合理，管理系统是件可怕的事，你签名他们的密钥并将其添加到存储中。问题在于，在底层，这一切似乎都能正常工作，但没有人愿意设计这个用户界面。没有人愿意编写所需的文档来向普通用户解释这些内容。没有人愿意运营24/7的呼叫中心，引导用户完成复杂流程，耐心帮助他们解决丢失密钥的问题，解释什么是信任根以及为何现在必须跳过这些步骤来设置它。
我倾向于相信，如果他们最初做对了，用户界面会被设计成一种“开箱即用”的模式，而用户群体也会被培养成习惯这些密钥生成步骤。但我也是个乐观主义者，所以或许并非如此，这正是我上面描述的令人恐惧且毫无回报的任务。但我们永远不会知道，微软选择了捷径，声称“我们来保管密钥”。如今你成了自己机器上的农奴。理论上存在自行安装密钥的方法，甚至可能有效，但该流程极为繁琐(从未真正设计用于大规模使用)，且你必须依赖供应商足够重视并启用该功能。许多供应商并不如此。
嗯，这基本上就是我们现在在主板上可以删除微软密钥并注册自己的密钥的情况。只是默认设置不同，且没有支持噩梦
我们甚至无法享受微软在这一领域专断决策带来的好处。主板总是会出现ACPI混乱等问题。
主板的ACPI等功能仍然比没有“Windows认证”(无论当前名称是什么)的程序要好。
只有法律要求才能改变这一点。如今，mokutil已经足够好，Linux用户可以围绕它构建一个工具，在启动时自动注册，这应该能缓解一些痛苦。但除此之外，这仍是一团糟，仍需法律要求。
欧盟应介入并确保任何关键操作系统认证不再由大型企业掌控。看看 GrapheneOS 如何在几乎没有理由的情况下被拒绝 Google Play Integrity [1]，且后果严重。此类安全基础设施易被滥用以在市场上引入偏见。另一方面，需要资金来专业运营这些系统。
[1] https://discuss.privacyguides.net/t/grapheneos-is-taking-act…
“欧盟应介入”
欧盟规定，所有销售的硬件只能启动由欧盟私钥签名的软件，且签名仅提供给包括政府间谍软件在内的软件，并需通过十亿欧元认证流程。
“不，不是那样！”
你不需要。我从所有系统中移除了微软的密钥，并注册了自己的密钥。
但你可以关闭它或注册自己的密钥。
这只是默认设置。你可以用自己的平台密钥覆盖它。
那些可能无法获得更新的设备在验证证书时不应使用当前日期/时间。相反，它们应该检查证书在固件编译当天是否有效(即行为不会因时间推移而改变)。
过期证书最多应作为可跳过的警告。没有人依赖证书过期来实现安全。如果你这样做，可能需要等待数年才能等到被盗证书过期——哈哈！
这绝对是一个微不足道的“顺便说一下，证书已过期，请检查更新”的问题，但各种系统却将证书过期视为世界末日般的锁定场景。
哦，当然可以跳过。只需拔掉CMOS电池，等待几秒钟后再插回即可。
将会有一群Linux用户编写一个关机脚本，将日期设置回2015年，然后关机……而在开机时，通过互联网将日期重置为今天。
听起来比文章中提到的任何解决方案都更干净！
这很冒险，不干净的关机需要重置时钟，这很麻烦。
更有可能的是，有人会编写一个驱动程序，为时钟添加一个偏移量，将硬件日期保持在安全范围内。
你可以简单地避免调整硬件时钟。内核时钟与之无关，可以单独修改。例如，chrony 可以做到这一点。
https://wiki.archlinux.org/title/Chrony#Real-Time_Clock
信息安全工程师讨厌这个小技巧！
>证书过期年限
代码签名证书的有效期正呈现缩短趋势。Ot最近从最长39个月缩短至约15个月。
这几乎完全背离了证书过期的初衷。可以通过要求签名对象由某种安全时间戳服务进行时间戳记来稍作改进。但此时应认真考虑安全启动(Secure Boot)默认证书旨在防范的威胁模型。
当信息安全极客们摆脱对有效期的不健康迷恋，并意识到系统在任意随机时刻不可逆转地崩溃，或需要真实时间源才能运行，这些设计与现实世界是完全不相容的，他们或许才能真正有所作为。在此之前，请不要打扰我们其他人试图完成工作(以及不得不清理你们制造的混乱——你们是什么意思，不能直接更新它？！)
那么，在此情况下，过期的目的是什么？
在这个特定情况下，过期时间没有任何意义。如果你设置了24小时的过期时间并不断更新，这还有点道理——被盗的证书只有很短的时间窗口。
然而，如果你设置了多年的过期时间，显然根本没有必要设置过期日期。你无法证明这有任何安全益处，想象一下用“被盗证书仅有效几年！”来安抚人们。
显然，为这种用例设置过期日期本身就是个错误，而多年过期日期本应是一个警示信号，让人们质疑“为什么我们为这种用例设置过期日期？”
如果没有证书过期，我可以通过找到一家1980年最后一次交易的破产公司，窃取他们的密钥来生成自己的证书。
有了过期日期，至少可以窃取证书签名密钥的地方池不会无限增长。
签名密钥的过期与使用这些密钥签名的签名过期是不同的。合同或引导程序的签名应无限期有效，即使签名者/密钥在某个时间点后不再被允许签名合同/引导程序。
这听起来难以执行。密钥签名是离线进行的。如果我拥有一个过期的签名密钥，有什么能阻止我将时钟调回几年，创建一个新签名并进行签名？
如果生成的密钥可以无限期使用，那么我签名密钥上的过期日期完全没有意义。
可信时间戳服务。https://en.wikipedia.org/wiki/Trusted_timestamping
微软的Authenticode早已实现这一功能，允许签名在签名证书过期后仍被视为有效。
https://learn.microsoft.com/en-us/windows/win32/seccrypto/ti…
那么，是什么阻止人们直接进入BIOS更改日期或拔掉时钟电池？我们在这里的观点是，至少对于这个应用程序而言，过期机制是没有意义的。
你可以通过找到一个在启动早期具有代码执行漏洞的软件，并且该软件由银行签名，来实现类似的效果。
另一种模型是仅允许在截止日期前已安装的EFI二进制文件启动，但这可能带来另一套复杂问题。
更糟糕的是，“当前日期”来自外部来源，任何能获取机器新镜像的人都可能篡改它。设置硬件时钟是内核可用的常规操作。
我好奇我的笔记本电脑接下来会怎么做。
联想在他们的“英明决策”下，决定在访问UEFI固件接口之前先加载一个由微软签名的Nvidia二进制文件。尝试安装自有安全启动密钥的人发现，他们甚至无法进入固件配置界面来撤销该更改。
他们的官方解决方法是仅通过固件接口加载安全启动密钥(而非标准的Linux工具)，该方法拒绝清除用于签名Nvidia固件的证书。然而，当该证书过期时，此解决方法显然将失效。
搭载AMD 7840U处理器的Framework笔记本在未注册任何微软密钥的情况下可正常运行。
对于当前笔记本，您可能可以通过`–tpm-eventlog`参数配合`sbctl enroll-keys`命令，将OptionROM的哈希值注册到白名单中以屏蔽该二进制文件。
使用“安全启动”与微软密钥并非真正的安全启动。它只是“微软决定你可以启动什么”。注册自己的密钥应是标准操作方式。shim 只是个笑话。
出于好奇，如今安全启动的体验如何？
我不得不关闭所有安装中的安全启动，因为 NVIDIA 驱动程序或 VirtualBox 模块的问题。总体而言，基于 Arch 的发行版似乎对安全启动的配置不太友好。
我给安全启动的体验打 6.5/10 分
如果你使用像 Ubuntu 这样的主流发行版，你可能发现安全启动可以开箱即用，无需折腾“机器所有者密钥”之类的东西。
Ubuntu 有像“linux-modules-nvidia-550-generic”这样的包，其中包含使用 Canonical 密钥签名的 Nvidia 550 驱动程序版本。如果一切顺利且该包被安装，你将获得可在安全启动下运行的NVIDIA驱动程序。
他们还提供了一个第二机制。你可以设置一个“机器所有者密钥”(MOK)，随后软件更新会自动触发构建新的NVIDIA内核模块，使用“dkms”并用MOK签名，从而使其能在安全启动下运行。
问题是这个过程可能有些不稳定。MOK设置过程需要重启并进入“MOK管理器”，这是一个看起来像上世纪80年代的界面。如果你不知道它的存在、用途，或者不擅长英语，很容易误操作而未能正确设置MOK。而且它只在单次启动时显示，除非你知道一个神秘的终端命令。
如果你在设置过程中遇到任何问题——你将不得不通过手机查找解决方案，因为你的电脑无法启动。
与此同时，第三种选择——直接关闭安全启动——非常简单(假设你知道什么是 BIOS)，而且每次都能成功。因此，许多“如何设置 NVIDIA 驱动程序”的指南都建议这样做。
尽管我对此有所抱怨，但我不得不承认，像动态编译和签名内核模块这样的功能能如此稳定地运行确实令人印象深刻——尤其是考虑到其中大部分工作是由志愿者维护的，他们无私地牺牲自己的闲暇时间，而他们本可以简单地在 BIOS 中关闭安全启动。
Mok 存在一个重大问题，即恶意软件可能利用它让你签名恶意代码。让签名密钥对最终用户可访问是危险的。
作为一名长期 Linux 用户(自 1997 年起，因此不可避免地保留了一些过去系统难以正常运行的不良习惯)，我的经验是：如果偏离“黄金路径”，事情会变得有些混乱；但如果你始终遵循“黄金路径”，你甚至不会注意到它已被启用。
我从戴尔等厂商购买的预装Linux的笔记本电脑都能正常工作。我通过多个版本的Ubuntu(16至24的LTS版本)进行系统升级的机器，在首次启用安全启动时曾出现过一段时间的异常故障，但考虑到这是极端案例，这种情况似乎可以理解。近年来我安装Debian的机器都运行正常，除了从软件RAID阵列启动时遇到一些问题，但那是因为我使用了2个相同的硬盘，并在UEFI启动配置中不断混淆它们。
我没有在搭载NVIDIA、VirtualBox或其他内核树外模块的机器上使用过它们。
每隔几年，微软都会发布一个更新，破坏多系统启动/双系统启动。我确信这是故意的，而且相对确定“安全启动”是他们实现这一目的的方式。
仍然只在Windows上玩儿童游戏。自上个千年以来就是Linux用户。
作为自2019年起仅使用Linux的游戏玩家，我想知道你所说的儿童游戏具体指哪些？
我已经不再尝试在Linux上安装东西了。任何涉及内核级反作弊机制的游戏似乎都让人头疼。他们允许《堡垒之夜》，以及相当一部分《漫威对决》(最初能用，后来停止了，我看到有报告称它又开始工作了，但我没有时间成为全职支持来确保一切顺畅运行)。
我们确实使用Kubuntu来运行那些在其中无障碍运行的游戏——《Risk of Rain》、《Roblox》(通过Sober)、浏览器游戏和《CS2》。
他们还被要求使用Microsoft Office进行学校作业(英国)，虽然可以在线使用，但体验似乎更差、更慢，且更容易出现问题。
顺便说一下，我使用Linux发行版已有数十年，直到第一个孩子上高中前一直只用Linux。微软的“教育”政策对他们确实有效！
像Roblox这样的应用程序在Windows系统下才能正常使用，这源于对“反作弊”机制的扭曲理解。
https://sober.vinegarhq.org/
我可以确认Sober运行得非常流畅，可能比Windows客户端稍顺畅一些。
我无法通过Proton/Wine运行它。
啊，我差点提到Roblox，但查看ProtonDB后发现它有黄金状态。所以应该能正常运行？
> 每隔几年，微软都会发布一个更新，导致多系统启动/双系统启动出现问题
据我所记得，上一次发生这种情况时，是由于 Linux 发行版没有及时更新包，而微软的更新只是提高了安全要求，导致那些疏于更新的发行版受到影响。
认为微软应该能够发布命令，而发行版必须遵守，这种想法是荒谬的。如果微软破坏了什么，那绝对是他们的责任。
不，不是这样。微软必须禁用过时且存在漏洞的签名启动加载程序，以防止它们被用于绕过安全启动。微软与红帽合作进行了更新，但某些发行版因疏忽大意，仍在使用过时且存在漏洞的启动加载程序。
我知道批评微软是常态，他们确实做了很多糟糕的事情，但在这种情况下，只是某些发行版没有认真对待安全更新，这就是为什么很多发行版没有出现问题(例如 Fedora)
所以Windows安装了破坏Linux启动的东西。你该如何启动Linux来安装修复程序？难道我每天要两次重启到其他操作系统检查更新？我这样做是不是在懈怠？！
不，Windows更新了UEFI组件，以禁用过时且存在漏洞的启动加载程序，防止它们被用于绕过安全启动。
我使用 Fedora 且已启用该功能。每次内核更新时，我都必须运行脚本重新编译并签名 VMware 驱动程序。我可能以后能弄清楚如何使用 DKMS 实现。偶尔会出现内核变更导致 VMware 驱动程序停止工作，这时我需要获取新补丁。
模块的签名维护可以完全自动化。注册只需一次操作，通过一个略显 intimidating 的界面接受新的 PKI。
对于你物理管理的系统来说没问题，但对于数据中心中的远程系统，我不会去麻烦 (没有外部动机)
这很奇怪，因为安全启动应该在_恰恰_你无法物理控制硬件的情况下有用，不是吗？我猜普通公司(不太重要的那种)的威胁模型中不包括恶意数据中心(而且安全启动在现实中是否能保护你值得怀疑)，但这不是其中一个动机吗？
你可以将其与TPM绑定以存储加密密钥，该密钥仅在启动参数与密钥匹配时生成。这是Windows已经实现的功能，但在Linux下并未完全支持，且存在一定安全隐患，因为无法加密initramfs(因此有人可能在启动过程中进行感染)。
解决这个问题的方法是存在的。但我认为你指出的问题确实是主流 Linux 发行版的核心问题。不过，情况不必如此。
你可以对 initramfs 进行签名和验证，这得到了引导加载程序的支持。
你可以将内核和 initramfs 合并到 UKI 中，并对整个镜像进行签名。
我不明白为什么没有实现这一点。
对于UKI，我认为一个主要障碍是镜像的大小(因为/boot/efi通常只够容纳引导加载程序，而非内核和initram)，以及自定义内核模块(如Nvidia)。
系统d曾对一个规范进行过工作，该规范旨在通过扩展EFI分区来存储内核镜像和initramfs，但目前没有发行版默认启用该功能。
我认为休眠功能目前也存在问题，因为休眠文件默认以明文形式存储，因此无法与安全启动兼容。
使用UKI时，initramfs也会被签名，对吧？
> 这很奇怪，因为安全启动应该在_exactly_你无法物理控制硬件的情况下有用，不是吗？
引入自有签名密钥的一种方式是作为机器所有者密钥(MOK)，使用“MOK 管理器”
但该软件的设计目标是：我们不希望具备 root 权限的恶意软件在未经用户同意的情况下引入 MOK，因为这样恶意软件就能自行签名。因此“MOK 管理器”被刻意设计为需要在启动早期阶段(网络尚未连接时)通过键盘和鼠标交互进行操作。
当然，如果你的服务器连接了KVM，你仍然可以远程操作，我想。
是的，不过在数据中心(DC)中，恶意管理员的门槛更高，需要更多文档。
我基于这种缓解措施和未知的运营痛苦而犹豫。有时值得，有时不值得。
使用Arch系统时，自sbctl [0]发布以来，我一直使用SecureBoot且未出现任何问题。当然，我并未使用任何NVIDIA硬件。
[0] https://github.com/Foxboron/sbctl
它基本上可以正常工作，除非你试图将 Linux 与 Nvidia 硬件结合使用。即使使用 Nvidia 硬件，要让它正常工作也不需要太多努力，但像往常一样，Nvidia 需要额外的步骤。
Linux 真正缺乏的是一个用户友好的方法来注册自己的密钥，这将立即解决所有 Nvidia/固件更新程序/自定义引导加载程序的问题。命令行工具正在逐步变得易于使用，但缺乏引导式操作流程。
我使用Arch系统，配置安全启动非常简单。我不明白你为何认为它不够友好。我使用UKI，因此无需启动加载程序，我的UKI由自有密钥签名并已安装到UEFI中。大多数签名过程由systemd处理，因此大部分已集成到基础系统中。
UKI + 安全启动配合得很好，但在Arch上的设置过程有点手动(什么不是呢)。
如果设置正确，你生成的文件只有：
– /efi/loader/random-seed
– /efi/EFI/Linux/arch-linux.efi
– /efi/EFI/Linux/arch-linux-fallback.efi
而所有.efi文件均通过钩子自动签名。
甚至可以跳过引导加载程序，直接启动镜像。
我刚刚完成此配置，确实非常简单。最困难的部分是将ESP扩展以实现与Windows的双启动，但这基本上只需将文件复制粘贴到更大分区并修改分区类型GUID即可。
大多数指南都专注于创建PK、KEK和db证书，以便从用户空间使用签名.auth文件进行证书注册/更新，但这实际上毫无意义且严重复杂化了流程。我直接使用openssl生成了一对20年的db密钥对(并为PK和KEK生成密钥以满足sbctl的要求，因存在一个漏洞)，随后手动将公共db证书通过ESP安装到UEFI中。甚至无需使用设置模式，不过我暂停了Windows分区的BitLocker，以便其在db更新后使用新的PCR 7测量值重新密封密钥。
为了完成安全设置，我为PK和KEK使用了单独的密钥，并已将微软的2023 UEFI证书安装到数据库中(并将2011证书添加到dbx中，同时更新了bootmgr)。
我只是使用sbctl在设置模式下生成并安装了平台密钥。它运行良好。
在使用Ubuntu自定义DKMS模块时，安装过程中有一个复选框。仅此而已。过去五年或更长时间都是如此。
刚刚用“Confirm-SecureBootUEFI”重新确认——我的笔记本电脑显示为True，该设备已使用超过1年。我确信之前使用了四年的系统也启用了该功能，且未发现任何问题。
Windows 10 及 11
这就是我为何避免且将始终避免使用“安全启动”的原因。我预计从九月起，许多新用户将因此被锁定。
或者你可以直接从系统中移除微软的密钥，并用自己的密钥签名启动加载程序。这就是我在所有系统上所做的，因此不受此影响。
_警告：用自己的密钥替换平台密钥可能会导致某些机器(包括笔记本电脑)的硬件变砖，无法进入固件设置进行修复。这是因为某些设备(如GPU)的固件(OpROMs)在启动过程中会被执行，而这些固件是使用微软第三方UEFI CA证书或供应商证书签名的。这种情况在许多联想ThinkPad X、P和T系列笔记本电脑中普遍存在，这些笔记本电脑使用联想CA证书来签名UEFI应用程序和固件。
“仅仅”这个词在该解决方案中承担了大量工作。
https://wiki.archlinux.org/title/Unified_Extensible_Firmware…
当然，但这比仅仅禁用安全启动要复杂得多，而且对于大多数人的威胁模型而言，这样做实际上并不会带来任何安全收益。
你有相关操作的具体来源吗？
Arch Wiki 提供了最佳的参考资料 https://wiki.archlinux.org/title/Unified_Extensible_Firmware…
注意 sbctl 是实现此功能的较简单工具之一。
我按照 https://github.com/nix-community/lanzaboote/blob/master/docs… 但如果你想避免使用微软密钥，自然不应在运行 `sbctl enroll-keys` 时包含 `–microsoft` 标志。此外，Lanzaboote 仅适用于 NixOS。
应该有一种“合理使用”认证，确保设备不支持安全启动，提供完全开放且可自行维护的硬件，在持续使用过程中独立于所有外部实体，并提供硬件开关以关闭内置功能(如端口、麦克风和摄像头)，以实现节能和安全。
若要获取Windows许可证、预装Windows系统、贴上Windows贴纸并向大众销售设备，您需要Windows兼容性认证，而该认证要求设备默认启用安全启动功能。
这听起来简直是反竞争行为。也许我们应该，我不知道；采取措施阻止公司利用合同条款将关键行业锁定在一种特定的运作方式中，以扼杀此类努力？
我们能做些什么？
“这会让微软生气还是高兴？”可能是许多OEM厂商在决定如何设计他们的机器时会想到的问题。
奇怪的是，微软一直是确保Linux在PC上可启动的公司之一。
微软一直在努力在对OEM施加微妙压力以使Linux难以启动(从而不让其变得更受欢迎)与不违反其反垄断协议条款之间保持平衡。
比尔·盖茨曾著名地问道：“我们能否创建一个标准或扩展类似ACPI的东西，以便Linux无法在PC上启动？”
因此，相信这一点非常、非常困难。
新加入的Linux用户应该会使用新的密钥吧？
研究安全启动的历史。发现英特尔和AMD处理器通过英特尔管理引擎[1]和AMD平台安全处理器[2]存在后门。这两者均为闭源软件，且多年来存在多个漏洞。它们本质上就是后门。
似乎禁用这些“功能”也几乎不可能。
[1] https://en.m.wikipedia.org/wiki/Intel_Management_Engine
[2] https://en.m.wikipedia.org/wiki/AMD_Platform_Security_Proces…
我没想到允许我们在微软的许可下启动 Linux 的安全启动证书是会过期的东西。因此，微软要终结用户端的 Linux 只需……什么都不做。
我们是怎么陷入这种境地的？在微软多年来暗中威胁人们因运行 Samba 和 Linux VFAT 而面临诉讼，并称开源软件为“癌症”之后？
文章应包含一种非常明显的方法，让用户测试自己是否受到影响。如何以一种非常清晰直白的方式验证，某个任意系统是否会在九月遇到此问题？
将系统时间设置为十二月，重启后观察结果。
微软能以这种方式插入Linux启动过程让我感到恼火。从道德角度而言，启动Linux时绝不应使用微软签名的密钥。
你不需要使用插件，只需按照这个链接https://www.rodsbooks.com/efi-bootloaders/controlling-sb.htm…操作。
自由操作系统是为符合微软硬件标准和兼容性测试(Windows HLK)的机器编写的，这些标准定义了与Windows兼容的硬件。Linux正在通过shim技术进入Windows的启动过程，而不是相反，即使是在制造商预装Linux的机器上也是如此。
如果你想在“道德层面”保持纯洁，无论这意味着什么，FSF必须制定自己的硬件标准并说服OEM厂商遵守。祝你好运。
这只是因为我们允许这种情况发生。微软本不应对此有任何影响。消费者保护法完全让我们失望了。
我今天才知道UEFI居然是“Windows启动过程”/s
我肯定这是个天真的想法，但为什么不能手动在BIOS(我承认这是EFI)中输入新密钥？
这是可行的，也是你应该做的事情。 “sbctl”(https://github.com/Foxboron/sbctl)据我所知，它在 Linux 上有一个合理的前端来完成这项任务(我不确定，我之前是手动操作的)。你需要在 BIOS/UEFI 选项中将系统设置为“安全启动设置模式”后再启动，这将允许你修改用于链式加载其他密钥的 PK(平台密钥)。(设置模式应在安装新 PK 时自动退出。)
如果你想双系统启动 Windows，可以保留 Microsoft 的密钥，只需用自己的 PK 重新签名这些密钥即可。
这在高端主板上应该可行吧？
这样你就能控制电脑上启动的内容了……
你实际上已经可以做到。你可以自行签名所有内容，并设置UEFI仅启动你的签名
仅限于x86安全启动实现。在大多数支持可信启动的设备上，你没有这个选项。
非x86系统的UEFI对大多数人来说根本行不通。而且U-Boot也未必更好
那将是一场灾难。或者想象一下，如果你只是禁用了安全启动，你的电脑将立即被病毒感染，银行账户也被清空，我猜
安全启动无法阻止用户空间的恶意活动。
我认为它只是帮助在企业安全清单上打勾，因为它表明正在启动的内核未被篡改。
楼主是在开玩笑
是的
你可能会认为，未经美国公司控制的人工过期日期，向欧洲出售计算资源是违法的。
这不仅仅是安全启动的问题。现代操作系统中到处都是证书。这些证书就像定时炸弹，可能在基于这些操作系统的硬件制造商并未意识到的设备中引爆。我想到的包括ATM机、投票机、医疗设备、智能冰箱和其他物联网设备，可能还有许多汽车等。
哦，他们当然清楚这一点。对他们来说，这只是另一个收入来源。计划性报废最终会摧毁我们的数字遗产。
那么，Grub更新是否可能破坏现有可引导节点？这让我担心，因为我有几台部署在现场的Linux桌面电脑，不记得是否启用了安全启动。
如果用户不更新密钥环或固件(例如通过fwupdmgr)，当证书过期时，Grub在安全启动启用时可能会停止启动。
如果用户在旧证书不再用于签名引导加载程序时更新Grub，但未更新密钥环或固件，当证书过期时，Grub在安全启动启用时可能会停止启动。
如果用户更新了系统和软件，Grub 将继续正常工作。
不更新并非解决方案，除非主板制造商真的搞砸了且未验证证书过期日期。
幸运的是，fwupdmgr 已集成到我所知的几乎所有 Linux 发行版的图形界面更新工具中。只要用户不忽略“系统有可用更新”的弹窗，且桌面厂商提供了基本软件支持，事情应该会顺利进行。
> 不更新并非解决方案，除非主板制造商真的搞砸了且不验证过期日期。
文章提到，大多数主板可能不会验证过期日期。仍存在担忧：新版本的Shim可能不会使用过期密钥签名，因此在不接受新密钥的硬件上无法启动。
安全启动、磁盘加密等功能在我看来麻烦多于好处。我已全部关闭。
注：针对不定期备份、测试备份等操作的个人电脑
安全启动的优势确实不那么明显(我认为在个人电脑上刷写自定义后门固件并非常见攻击方式)，但全盘加密(FDE)在笔记本被盗时仍具实用性，因为窃贼在硬盘中搜寻敏感数据的情况确实存在。
我也不认为这会带来太大麻烦。如果你有TPM并使用systemd，可以设置在开机时自动解锁FDE，否则只需在开机时输入额外密码即可。
安全启动(SB)完全无法防范后门固件。你需要像BootGuard这样的独立功能。
你能详细说明一下吗？这不是安全启动的全部意义吗？
我的理解是，至少在 Android 上你无法修改系统：如果你想在这个层面上进行更改，就必须格式化一切。
不，SB 实际上是从固件启动开始的。它只是整个链条中的一环。你也可以查阅可信启动(Trusted Boot)和安全启动(Secure Launch)，了解整个链条如何实现安全。
> SB 实际上是从固件启动某个组件开始的。
我不明白这句话的意思。也就是说，与 Android 系统中通过 ROM 中的引导加载程序启动下一个引导加载程序并验证其签名的方式不同(我认为 Android 就是这样工作的？)，在笔记本电脑上，第一个引导加载程序可以由用户安装，而没有任何机制来验证其签名？
EDIT：我在此处[1]读到，安全启动从 ROM 验证直至启动“Windows 内核”(在 Windows 系统中)。但这对我来说并不完全清楚：例如在 Linux 系统中，如果安全启动验证至我的 /boot 分区(它会这样做吗？)，那么由于我对剩余部分启用了 FDE，应该没问题，对吧？
[1]: https://learn.microsoft.com/en-us/windows/security/operating…
> 在笔记本电脑上，第一个引导加载程序可以由用户安装，而且没有任何机制检查其签名吗？
它应该由制造商签名，所以你应该无法做到。它由一个更小的CPU中的shim加载，是Boot Guard和平台安全启动的一部分，如果我记得没错的话。
> 例如在 Linux 中，安全启动是否会验证我的 /boot 分区(它会吗？)
不会。它只验证一个签名文件，通常是 Grub EFI 启动加载程序。该文件随后应验证你想要验证的一切。与 Windows 不同，桌面 Linux 发行版通常没有最佳的安全启动系统。Poettering 曾对此问题进行过详细描述。
因此，到了2025年、2026年，BIOS的简单性仍然困扰着我们。我明白这次是一个单独的证书问题，但安全启动和UEFI实现中已经出现了太多其他非 trivial 的问题，我忍不住将即将到来的修复视为一场固定/失败/砖化的轮盘赌。
我可以肯定地说，这次更新并不完全顺利。我在Fedora中有一个待处理的KEK更新，但这是一个测试密钥(已提交错误报告，但目前尚未有进展)。
[警告：我对针对安全启动的刻薄言论或无知抱怨不感兴趣，此类内容已比比皆是]
我希望从真正理解安全启动机制的人那里获得见解。我对Android的理解(针对少数正确实现安全启动的Android制造商)是：ROM中某个位置烧录有无法更改的“制造商密钥”，且一旦系统首次正确安装：
除非从已安装的操作系统解锁引导加载程序，否则无法覆盖系统分区(我假设某种机制确保只有签名操作系统才能解锁引导加载程序？)
一旦解锁引导加载程序，就无法仅覆盖系统的一部分：只能全部覆盖或完全不覆盖，因此无法向现有系统注入内容(恶意女仆式攻击)。
在Android系统中，可以添加自定义密钥。这就是GrapheneOS等系统所采用的方案。
UEFI系统中情况如何？听起来“制造商密钥”始终来自微软，但是否存在使用自定义密钥的途径？
当然可以使用自定义密钥。至少在我拥有的所有EFI计算机上都是可能的。不存在“制造商密钥”。BIOS中通常有一个恢复默认配置的选项，该选项会重置为微软密钥，但你可以删除所有微软密钥。
不过可能存在进一步的复杂情况，例如部分联想笔记本使用由微软密钥签名的固件包，若删除微软密钥，可能导致笔记本无法启动，因为显卡将无法启动。不过我目前正在使用联想ThinkPad T14s Gen4 Intel型号，已删除所有密钥并添加自定义密钥，系统运行正常。可能是AMD相关问题。
> 现在可能会有进一步的复杂情况，例如一些联想笔记本电脑使用由MS密钥签名的固件块
哦，对！是的，如果你想使用自定义密钥，你需要能够构建并签名你的操作系统，而专有固件就会成为问题。现在我好奇为什么这在Android上不是问题……是因为固件块来自你自己签名的镜像吗？
解决方案是否是让 GPU 从操作系统加载固件？
你不需要能够构建它们。只需签名它们或签名签名第三方 blobs/二进制的密钥。
然后你的主板固件就能将你的GPU和其他第三方固件加载到UEFI内存中。同样，像Linux和Windows这样的操作系统也强制执行相同的信任链(它们不必这样做，但否则就真的不安全，就像一个网站可以向你撒谎关于加密存储一样)，所以你需要你的驱动程序/操作系统加载的固件也必须签名。
Android 和 UEFI 的工作原理其实并不相关。这就像比较 SSH 的身份验证方式与 HTTP 结合 TLS 的身份验证方式。前者是 SSH 特定的开放式实现细节，后者则由 IETF 标准化。
同样，UEFI 标准化了主板制造商如何编写兼容的固件，而“安全启动”(大写)是 UEFI 的子规范。它并非唯一的安全启动实现方案。
在 Android 设备中，制造商对早期启动固件和操作系统拥有完全控制权。只要他们能启动操作系统以运行应用程序，具体实现方式由他们自行决定。只有像 Google 的 SafetyNet 这样的服务会对他们提出某些要求。在 Android 手机世界或其他任何地方(除 PC/服务器外)，都不存在类似 UEFI 的标准。
> 在 Android 系统中，仍可添加自定义密钥。这就是 GrapheneOS 等系统所采用的方案。
据我所知，这取决于所使用的硬件。谷歌 Pixel 设备允许此操作，但并非普遍支持。在 XDA 论坛上可以找到许多尝试锁定引导加载程序导致手机变砖的案例。
> 据我所知，这取决于所使用的硬件。Google Pixel 允许这样做，但并非所有设备都支持。
你说得对！这就是我提到少数几家正确实现这一功能的制造商。GrapheneOS 仅支持 Pixel，原因并非如此。CalyxOS 支持其他设备(其中一个限制是能够重新锁定引导加载程序)。/e/OS似乎不太在意安全启动。
> 在XDA上可以找到很多关于人们尝试锁定引导加载程序导致手机变砖的故事。
这引发了一个问题：重新锁定引导加载程序的意义何在？如果覆盖密钥意味着整个系统将被格式化，那么我看不出来为什么应该阻止这种操作？如果一个恶意用户想让我丢失数据，他们可以带走笔记本电脑，对吧？
> 听起来“制造商密钥”总是来自微软，
UEFI 中的主密钥称为“平台密钥”(PK)，只能有一个，且由主板制造商生成，而非微软。PK用于签名密钥交换密钥(KEK)，通常会有2到4个，包括微软自用密钥、微软第三方密钥、主板供应商密钥以及系统/主板专用密钥。
除了这些，还能加载自定义密钥吗？
您需要用自己的 PK 替换默认 PK，因为它用于签名所有其他密钥，且通常只能存在一个 PK。您可以使用自己的 PK 重新签名现有密钥(例如，如果您想双启动 Windows)——或直接弃用现有密钥¹，以及/或生成其他类型的密钥(KEK 和 DB)。
编辑：¹ 在某些情况下，丢弃现有密钥会导致系统故障，因为主板厂商愚蠢地用其中一个密钥签名了VGA UEFI驱动程序，而不是将其直接嵌入BIOS/UEFI镜像中。据我所知，这仅影响特定型号的联想笔记本电脑，但在破坏系统前请先通过谷歌搜索详细信息。
编辑#2：实际上，我认为PK签名仅在将密钥添加到KEK/DB列表时进行验证，因此无需重新签名现有微软密钥，它们会默认保留在列表中。(除非它们被某种方式清除。)我上次操作这个已经有一段时间了。
需要注意的是，使用 Linux 时完全可以启用安全启动且不受任何影响。据我所知，大多数(如果不是全部)UEFI 固件都允许注册自己的密钥。如今管理安全启动只需安装 sbctl 并添加一个钩子，在重建 initramfs 时对内核进行签名即可。如文章所提，新密钥可在系统在线时更新，且不会被察觉。
关于安全启动的恐慌宣传对谁都没有好处，除了少数例外情况，你始终掌控着自己的系统。
安全启动允许微软默认启用全盘加密，我认为这对所有用户都是好事。它也允许你在Linux上实现相同功能。它让服务器管理员确信系统未被篡改。尽管UEFI存在诸多问题，但SB并非其中之一。
有些硬件需要驱动程序才能进入BIOS。这些驱动程序使用MSFT密钥签名。如果你切换到自己的密钥，你会发现甚至无法进入BIOS。
难道不能先断开互联网连接，将BIOS时钟设置为过期日期之前的日期，从安全安装介质启动，然后在安装完成后再将时钟恢复到正确时间吗？
在Ubuntu中有没有可靠的命令可以检查安全启动密钥及其过期日期？
mokutil
查看其各种选项
输出中的“有效性”字段将显示过期日期。
mokutil 实际上并不是用于此目的的正确工具，它列出了通过 Shim 安装的机器所有者密钥(MOK)。这里讨论的是通过 UEFI 安装的密钥交换密钥(KEK)。如果你不了解情况，看到空的密钥列表会感到非常困惑。它实际上可以显示 KEK，但你需要知道这首先是一个 KEK 相关的问题……
如果你真的想使用 mokutil，这就是魔法咒语
>目前，shim 由 2011 年签发的微软密钥签名，该密钥将于 9 月 11 日过期。
为证书添加过期日期提供了什么安全优势？“哦不！有人获得了我们的密钥并正在签发新的shim！……别担心，证书将在14年后过期。一切正常！”
有人知道这种过期日期的理由吗？
是否因为更快的证书轮换会阻碍甚至阻止技术普及？
幸运的是，我只使用从垃圾堆里捡来的旧硬件，这些硬件足够老旧，还保留着BIOS启动模式。
这只是又一个制造电子垃圾的因素。目前我可以在30年前的硬件上安装30年前的系统(假设我能保持机器和安装介质的良好状态)。而对于当前的计算机，这将不可能实现，因为它们将被标记为“不受支持”。
如果无法更新证书，只需禁用安全启动。你仍然可以使用你的电脑。
我一直都是
安全启动关闭 磁盘加密关闭 TPM关闭 缓解措施=关闭 在Linux内核命令行中
去他妈的安全启动。一个有趣的项目，即使主要是为了教育目的，就是收集过去几年发现的所有不同漏洞，并尝试创建一个通用的安全启动绕过加载器，尽可能多地针对这些漏洞。我猜如果你的供应商没有更新固件以包含较新的微软密钥，他们可能也没有修复任何漏洞。所以我们只需要让这个超级漏洞加载器签名，这样它就能在任何地方工作：o)
我们可以在关机时将时钟调回，开机时调回吗？还是说密钥会在日期过后自动删除？
简而言之，使用安全启动的 Linux 系统依赖于微软于 2011 年签发的证书，该证书将于 2024 年 9 月 11 日过期。此后，使用安全启动的新 Linux 安装可能无法启动，除非系统固件包含微软 2023 年的新密钥，而更新密钥通常需要硬件供应商提供固件更新，但这并不总是发生。令人震惊的是，许多用户在不知情的情况下依赖过时的微软密钥(我将检查自己是否在其中，真是令人沮丧)。不过，人们开始关注这个问题也是件好事。
> 启用了安全启动的 Linux 用户，无论知情与否，都依赖于微软的一把密钥，该密钥将于九月到期。
不，我没有，因为我安装了自己的密钥，你也应该这样做，我们能停止假设安全启动意味着微软密钥吗？
> 任何已安装的发行版都应使用自己的密钥签名引导加载程序，以确保继续引导
我有点担心：只要没有强制性的安全更新需要重启，我就是那种能让桌面系统连续运行六个月的人(没错，Linux就是这么稳定，和Windows完全不同)。
所以我担心在x个月后无法启动，却忘了原因(啊，是的，微软的密钥过期了)。
我的理解是否正确，即这仅影响我的安装介质，而不影响已安装的系统？
最新稳定版 Debian，供参考。
唉，看来我回家后得用 mokutil 之类的工具了。
这就是我为什么不加密的原因。
安全启动与加密无关。它只是验证加密签名。引导加载程序是签名的，而不是加密的。
安全启动与加密之间确实存在某种关联。
如果你不启用安全启动，就需要通过其他方式保护引导链，以防止攻击者修改软件来记录输入的密码。
安全启动允许构建一个可验证的软件链(UEFI -> 引导加载程序 -> 内核 -> initrd)，这将防止任何修改，因此你可以确信你的键盘输入不会被恶意软件记录。不过，常见的 Linux 发行版在保护 initrd 方面存在一些问题，但这是这些发行版自身的问题。
另一个关键点是TPM。我将系统配置为将加密密钥存储在TPM中，并仅在启用安全启动时释放密钥。这使得系统能够自动解密根分区，无需输入密码，且我的配置仅允许加载使用我的密钥签名的UKI内核。当然，这在安全性和便利性之间做出了权衡(因为现在攻击者如果盗取了我的电脑，只需突破gdm或采取其他攻击方式，如提取内存条)，但对我来说是可以接受的。
这就像说在门上安装锁与设置陷阱之间存在某种联系，因为如果你不锁门，就需要设置陷阱来防止小偷偷走你的东西。它们都在试图缓解同一威胁，但在我家门前安装的40磅炸药与一个只能通过特定形状的金属部件操作的复杂金属圆筒之间没有关联。
我个人会同时使用安全启动和加密。
不，这就像说在门上安装锁和确保锁不能被替换成需要他人钥匙的锁，或者更糟糕的是能复制插入其中的钥匙的锁之间存在关联。威胁模型直接重叠。
这是一个很好的类比，指出仅依赖加密而不使用安全启动的弱点，但如果不解释“确保锁无法被替换”的机制，人们可能会错误地认为“它们都涉及设置锁，因此它们是相关的”，而“确保锁无法被替换”涉及保护放置锁的环境，例如 “确保铰链不外露，以免门从外部被拆下并替换为看似相同的门。”
我认为这主要是为了防止有人将你的SSD插入其他电脑并访问所有文件。其他威胁对大多数人来说可能并不现实。
安全启动对防止这种情况毫无作用。磁盘加密与安全启动无关。
对大多数人来说，这是一种无关紧要的威胁模型。有人可以偷走我的笔记本电脑，但如果他们不知道我的密码，就无法访问我的数据。故事到此结束。他们必须在不偷走笔记本电脑的情况下破解它，才能安装任何能够读取密码的工具。这种情况何时会发生，而你却毫不知情？你必须在处理高度敏感且备受追捧的材料时，才会有人尝试这样做。
除非你使用的是SED，否则你的EFI系统分区是未加密的。构建一个恶意版本的流行开源UEFI引导加载程序(如grub、refind、zfsbootmenu等)，并制作一个可引导的USB驱动器，该驱动器会扫描你的EFI系统分区，用恶意引导加载程序替换未加密的引导加载程序，这将非常容易。这种攻击可以由相对缺乏技能的人在几分钟内完成(“启动这个闪存驱动器，等待屏幕显示‘完成’，然后关机”)。我希望你的笔记本电脑永远不会在你手中离开超过几分钟！(例如，机场的TSA、Geek Squad或其他维修中心，或者经典的“恶意女仆”)。
安全启动不进行加密，安全启动仅进行签名。
但解锁TPM(使用其上的加密密钥)是启动验证的重要组成部分。
你将安全启动与测量/验证启动混为一谈。
它们不协同工作吗？我记得我是通过sbctl(securebootctl)启用安全启动，并使用同一工具将密钥注册到TPM中。
还是说这只是一个技术细节，在实际操作中属于同一工具和设置？
默认情况下，安全启动状态是TPM寄存器的一部分，用于解密你的驱动器加密密钥。这是因为如果你禁用安全启动，或使用不同密钥重新配置它，任何引导加载程序都可以将普通Linux系统的测量结果重放给TPM并解锁你的驱动器。
如果你愿意，可以选择使用不同的寄存器集。Arch Wiki上有很多相关信息：https://wiki.archlinux.org/title/Trusted_Platform_Module#Acc…
使用 –tpm2-pcrs 选项调用 systemd-cryptenroll 可手动选择一组选项。我认为 Bitlocker 使用 0、2、7 和 11(其中 11 是操作系统特定的寄存器而非规范定义的寄存器)，这就是为什么固件更新通常会要求你重新输入 Bitlocker 密钥。有些人选择仅记录安全启动状态，依赖固件自行验证其更新和配置，这意味着只要安全启动状态保持不变，固件更新后您无需使用恢复密钥。
不考虑安全启动状态会让整个设置变得非常容易绕过，但你可以这样做来让你的设置更难被破解，同时仍然防范“小偷偷走我的SSD但不偷走我的笔记本电脑”的场景。
除了jeroenhd的精彩回答外，你还可以使用TPM对安全启动签名密钥进行加密。这样做的好处是你的签名密钥无法被盗取，从而确保你的启动加载程序是在特定物理机器上签名的。但这并非必要，你可以将签名密钥存储在SSD上或任何你想要的位置/方式。
每当有人提出这一担忧时，都会被贴上“阴谋论者”的标签并被“标记”或静音，即被审查
快进到今天，你们都被深深地坑了
去他妈的微软
安全启动太邪恶了。
不，它不是。没有用户控制的安全启动才是邪恶的。UEFI通常允许用户控制。当然，供应商可以制作一个不允许用户密钥的UEFI系统……不要购买这样的系统。