我刚刚从官方网站下载了 Pop!_OS 22.04 LTS (NVIDIA) ，验证了校验和，刷到了笔式驱动器，并尝试从它启动。
我忘记按照网站上的建议禁用安全启动，所以不出所料，我收到了一条错误消息。然而，消息的实际内容让我感到惊讶：
在 SecureBoot 排除数据库 ('dbx') 中找到操作系统加载程序签名。所有可启动设备均未通过安全启动验证。
虽然我确实希望在签名数据库中找不到签名，但我没想到会在排除数据库中找到它。
根据这个网站：
dbx，“禁止签名数据库”。此处的条目通常是特定 UEFI 二进制文件的 SHA256 哈希，即那些由“db”列表中的证书签名但后来发现是坏的东西（例如，具有危害固件的安全漏洞）。所以这是一个“阻止”列表。
为什么 System76 提供的软件签名可能曾经有效，但后来被发现是坏的？
这是 Pop!_OS 中存在潜在漏洞的迹象吗？
2020 年年中，发现了一个名为CVE-2020-10713 或 BootHole的安全漏洞。它影响了几乎所有使用带有 Secure Boot 的 GRUB2 并且
acpi在其与 Secure Boot 兼容的配置中包含 GRUB 模块的发行版。此后，安全研究人员将更多注意力集中在启动过程上，以寻找其他类似的漏洞。这导致在 2021 年 3 月在 GRUB2 中发现、修复和发布了一组进一步的漏洞。除此之外，Debian 不得不撤销其旧的安全启动签名密钥，创建新密钥并对其引导加载程序签名过程进行一些更改。由于 Ubuntu 有类似的安全启动基础设施，他们必须做很多相同的.
其他从 Debian/Ubuntu 复制其安全启动基础设施的发行版也必须这样做，因为安全研究人员项目的另一部分是收集易受攻击的 GRUB 和
shimx64.efi版本的哈希列表并撤销安全启动签名密钥。该列表将被添加到未来安全启动固件的排除数据库中，并最终作为安全启动排除数据库更新分发到现有系统。2022 年 8 月 9 日，Microsoft 发布了适用于 Windows 的安全启动排除数据库更新，其中包括针对易受攻击版本的 GRUB 的排除；还为 Linux
fwupd/fwupdmgr系统发布了 Secure Boot dbx 更新。假设 Linux 发行版和操作系统供应商之间进行了一些协调以确保涵盖所有主要操作系统，这似乎是合理的。现在，如果 Pop!_OS 的引导组件现在与最新的排除列表匹配，则表明它们源自 2021 年 3 月之前的 Debian，或者换句话说，它们的级别相当于 Debian 10.9 或更早版本。Pop!_OS 似乎跳过了一些更新。
当然，他们建议禁用安全启动，但由于 Pop!_OS 是基于 Ubuntu 的相应版本，Ubuntu 对安全启动的支持表明 Pop!_OS 22.04 LTS 也应该可以实现功能性安全启动支持。也许 System76（Pop!_OS 的开发人员）选择跳过从 Microsoft 获得安全启动证书？对我来说，这表明 Pop!_OS 的重点可能更多地放在风格上而不是实质上。
基本上，2022 年 8 月 9 日的安全启动撤销是为了消除一种错误的安全感，以防您仍在使用易受攻击的组件：您的系统并不比一开始没有安全启动的系统更容易受到攻击。
如果您的系统在物理上是安全的，那么攻击者应该没有切实可行的方法来利用这些漏洞作为进入系统的途径。但是，如果您依靠安全启动使 Evil Maid 类型的攻击比您的“预期”级别的攻击者更难实现，那么看起来 Pop!_OS 目前可能是该用例的错误选择。