有没有办法判断我的EFI引导加载程序是否会接受二进制文件的签名而不重启？

假设我刚刚grub2在Linux或（更具体的）基于Debian的系统中的机器上安装了签名的EFI引导加载程序（例如，来自联想IdeaPad U410上的Ubuntu 14.10 amd64，它只能以安全引导EFI或传统模式引导）。有没有办法告诉机器在没有重启的情况下从运行中启动？

是的，但您必须拥有安全启动密钥。首先，请注意安全启动公钥至少可以采用三种形式：

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

如果您已使用MokManager安装了自己的机器所有者密钥（MOK），则应将文件放在.cer/ .derform中。如果你想测试二进制文件在用另一个密钥启动时是否有效（例如用于签署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将启动OK，而使用相同密钥签名的二进制B将失败。我相信这是受影响的UEFI中的一个错误，但我没有详细调查过。AFAIK，它不会影响通过Shim验证的二进制文件，但它可以影响Shim本身或没有Shim帮助启动的二进制文件。