我刚刚从以下网站下载了 Pop!_OS 22.04 LTS (NVIDIA)官方网站，验证校验和，闪存到笔式驱动器，并尝试从它启动。
我忘记按照网站上的建议禁用安全启动，所以不出所料，我收到了一条错误消息。然而，邮件的实际内容却让我大吃一惊：
在 SecureBoot 排除数据库（“dbx”）中找到操作系统加载程序签名。所有可启动设备均未通过安全启动验证。
虽然我确实希望在签名数据库中找不到签名，但我没想到会在排除数据库。
根据这个网站：
dbx，“禁止签名数据库”。这里的条目通常是特定 UEFI 二进制文件的 SHA256 哈希值，即那些由“db”列表中的证书签名但后来发现不好的东西（例如，具有危害固件的安全漏洞）。所以这是一个“阻止”列表。
为什么System76提供的软件签名曾经有效，但后来发现是错误的？
这是 Pop!_OS 中存在某些潜在漏洞的迹象吗？
答案1
2020 年中，出现了一个名为CVE-2020-10713 或 BootHole被找到。它影响了几乎所有使用 GRUB2 和安全启动并将 GRUBacpi模块包含在其安全启动兼容配置中的发行版。在此之后，安全研究人员将更多注意力集中在启动过程上，以寻找其他类似的漏洞。
这导致 2021 年 3 月在 GRUB2 中发现、修复并发布了一组更多漏洞。除此之外，Debian 还必须撤销旧的安全启动签名密钥，创建新密钥并对引导加载程序签名过程进行一些更改。由于 Ubuntu 有类似的安全启动基础设施，他们必须做同样的事情。
从 Debian/Ubuntu 复制安全启动基础设施的其他发行版也必须这样做，因为安全研究人员项目的另一部分是收集易受攻击的 GRUB 和shimx64.efi版本的哈希值列表，并撤销安全启动签名密钥。该列表将添加到未来安全启动固件的排除数据库中，并最终作为安全启动排除数据库更新分发到现有系统。
2022 年 8 月 9 日，Microsoft 发布了 Windows 安全启动排除数据库更新，其中包括 GRUB 易受攻击版本的排除；还发布了适用于 Linux fwupd/系统的安全启动 dbx 更新fwupdmgr。假设 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 目前可能是该用例的错误选择。