☰

安全启动究竟如何工作？

tag-icon • tag-icon boot grub2 grub-efi secure-boot signature
安全启动究竟如何工作？

我正在使用 GRUB2、SecureBoot 和内核签名，我认为我在安全启动中发现了一个可能的错误，但我想先检查一下我对这些过程的理解。

我知道，启用安全启动后，只有固件中加载的密钥签名的二进制文件才能启动，因此所有引导加载程序都必须经过签名。典型情况是 shim 和 GRUB。

如果启动失败或者您需要导入或删除一些密钥，Shim 应该启动 MoakManager，如果一切正常，它应该启动 GRUB，即真正的引导加载程序。

问题是我刚刚生成了一个自定义版本的 GRUB，grub-mkstandalone我用用 OpenSSl 创建的新密钥对其进行了签名；我还没有在固件中导入这个密钥，但是 shim 能够在没有任何安全启动报告的情况下启动它。

我检查了密钥mokutil --list-enrolled并且它仅报告了规范证书。


总结一下：

在我的 EFI 分区中我有：

  • shimx64.efi 由 Canonical 签名，使用 grub-install 生成
  • 我的自定义 GRUB，使用 grub-mkstandalone 生成，用我自己的密钥签名，我还没有导入，名为grubx64.efi。

在启动时 SHIM 可以启动 GRUB，并且 GRUB 可以成功启动 Ubuntu。

如果某些安全启动仅检查第一个引导加载程序的标志，而其他加载程序负责验证自身以及它们预加载的模块和用户最终加载的模块，那么这里的安全问题就非常高。

我会做更多的测试，但也许我应该打开一个错误单。


有任何想法吗？

答案1

我相信你的理解是正确的，除了shimx64.efi通过包以二进制形式交付，不是通过本地生成grub-install。（grub-install很可能安装 shimx64.efi（但是对于 ESP。）哦，它是 MokManager，而不是 MoakManager。

在提交错误报告之前，您应该回溯您的步骤并 100% 确保您是通过本地编译的 GRUB 进行启动的。efibootmgr例如，很容易意外地将二进制文件放在错误的位置或忘记运行以调整启动顺序。（您尚未描述如何安装自定义文件grubx64.efi- 您是覆盖标准 Ubuntu 二进制文件还是将新文件放在其他地方并通过 注册它 [和 Shim 的副本] efibootmgr？）您可能需要运行sudo efibootmgr -v以查看启动详细信息。请注意BootOrder和BootCurrent行 - 前者告诉您尝试启动选项的顺序，后者显示用于启动计算机的选项。您需要将数字与Boot####描述每个启动选项的各个行进行交叉引用。如果您安装了与 Ubuntu 的 GRUB 不同的自己的 GRUB，则可以想象固件会因为安全启动错误而悄悄绕过它，然后返回到原始的 Ubuntu Shim/GRUB，这可以解释您所看到的内容。

另一种可能性是您的计算机实际上并未启用安全启动。您可以按如下方式检查这种可能性：

$ hexdump /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c 
0000000 0016 0000 0001              
0000005

在此示例中，输出的第一行 ( 0000000 0016 0000 0001) 以 结尾1。这表示安全启动处于活动状态。如果以 结尾0，则表示您的计算机上的安全启动已禁用。

另一种可能性是，您可能以某种方式将本地密钥安装在固件自己的数据库列表中。不过，这是一项艰巨的任务，因此您不太可能在无意中完成了此操作。（请参阅我关于这个主题的页面有关如何设置的详细信息。）我提到这种可能性主要是为了完整性；除非您省略提及以前以这种方式掌握安全启动的尝试，否则我根本不会想到这种可能性。

如果您发现错误，则可能是在 Shim 中或在您的固件中。

还有一个需要注意的问题是，我对 GRUB 特定的工具（例如）并不十分熟悉grub-mkstandalone。由于我维护 rEFInd，所以我更喜欢使用它，所以我对 GRUB 工具的了解并不那么深入。因此，我可能会遗漏一些关键细节，因为它是 GRUB 特定的。

相关内容