有没有办法判断我的 EFI 引导加载程序是否会在无需重启的情况下接受二进制文件的签名？

Question

假设我刚刚grub2在 Linux 或（更具体）基于 Debian 的系统内的机器上安装了已签名的 EFI 引导加载程序（例如，从只能在安全启动 EFI 或传统模式下启动的 Lenovo IdeaPad U410 上的 Ubuntu 14.10 amd64）。有没有办法告诉机器将在运行过程中启动而无需重新启动？

Answer 1

是的，但你必须手头有安全启动密钥。首先，请注意安全启动公钥至少有三种形式：

• .cer/.der文件 —— 这些文件被大多数 UEFI 实现以及与 Shim 配对的 MokManager 工具使用。
• .crt—— 大多数 Linux 安全工具本身都使用这些文件，例如sbsigntool和sbverify。
• .esl-- 这些文件将多个密钥组合成一个文件。（其他文件每个都包含一个密钥。）如果您使用固件用户界面或 KeyTool 保存密钥，则生成的文件将采用这种格式。

如果您使用 MokManager 安装了自己的机器所有者密钥 (MOK)，则文件应为.cer/.der形式。如果您想测试二进制文件在使用其他密钥（例如用于签署 Ubuntu 或 Fedora 版本的 GRUB 的密钥）启动时是否能正常工作，则必须获取它。为方便起见，我使用 rEFInd 收集了几个；您可以逐个下载它们这里。如果你完全控制系统上的安全启动，您还应该已经拥有您创建的密钥。

要验证二进制文件，您必须拥有一个密钥.crt。如果您拥有密钥.der或密钥.cer形式，则可以将其转换：

openssl x509 -in mykey.cer -inform der -out mykey.crt

然后，您可以检查二进制文件是否正确签名：

sbverify --cert mykey.crt binary.efi

结果应该是一条消息阅读Signature verification OK或Signature verification failed。

请注意，某些 UEFI 甚至无法启动正确签名的二进制文件。这似乎是随机的；二进制文件 A 可以正常启动，而使用相同密钥签名的二进制文件 B 则失败。我相信这是受影响的 UEFI 中的一个错误，但我没有详细调查过。据我所知，它不会影响通过 Shim 验证的二进制文件，但它会影响 Shim 本身或没有 Shim 帮助启动的二进制文件。