问在SecureBoot排除数据库('dbx')中找到的操作系统加载器签名。所有可引导设备都失败了安全启动验证

EN

在2020年中期，发现了一个名为CVE-2020-10713或启动孔的安全漏洞。它影响了几乎所有使用带有安全引导的GRUB2的发行版，并将GRUB acpi模块包含在与安全引导兼容的配置中。在此之后，安全研究人员将更多的注意力集中在引导过程上，以发现其他类似的漏洞。

伴随着这导致在2021年3月在GRUB2 2上发现、修复和发布了一组更多的漏洞.，Debian不得不撤销他们以前的安全启动密钥，创建新的密钥，并对他们的引导加载程序签名过程进行一些更改。因为Ubuntu有类似的安全启动基础设施，他们也不得不做同样的事情。

从Debian/Ubuntu复制其安全引导基础设施的其他发行版也必须这样做，因为安全研究人员项目的另一部分是收集易受攻击的GRUB和shimx64.efi版本的哈希列表，并撤销安全启动签名密钥。该列表将添加到未来安全启动固件的排除数据库中，并最终作为现有系统的安全启动排除数据库更新分发。

2022年8月9日，微软发布了适用于Windows的安全启动排除数据库更新，其中包括对易受攻击的GRUB版本的排除；还为Linux fwupd/fwupdmgr系统发布了安全引导dbx更新。假设Linux发行版和OS供应商之间进行了一些协调，以确保涵盖所有主要的OSs，这似乎是合理的。

现在，如果Pop！_OS的引导组件现在与最新的排除列表相匹配，这将表明它们起源于2021年3月之前的Debian，或者换句话说，其级别相当于Debian 10.9或更高版本。Pop!_OS似乎跳过了一些更新。

当然，他们有一个禁用安全引导的建议，但是由于Pop!_OS是基于Ubuntu的相应版本，Ubuntu对安全引导的支持表明Pop!_OS 22.04 LTS也应该可以实现功能性的安全启动支持。也许System76 (Pop！_OS的开发人员)选择跳过从微软获得安全启动证书吗？对我来说，这意味着Pop_OS的关注点可能更多的是风格，而不是实质。

基本上，2022年8月9日的安全启动撤销是为了消除一种错误的安全感，以防您仍在使用易受攻击的组件:您的系统并不比一开始没有安全启动的系统更易受攻击。

如果您的系统在物理上是安全的，则攻击者不应该使用这些漏洞作为进入系统的方法。但是，如果您依赖安全启动使邪恶女佣类型的攻击比您的“预期”级别的攻击者所能达到的难度更高，那么现在看来Pop!_OS可能是该用例的错误选择。