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

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

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

答案1

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

  • .cer/.der文件 —— 这些文件被大多数 UEFI 实现以及与 Shim 配对的 MokManager 工具使用。
  • .crt—— 大多数 Linux 安全工具本身都使用这些文件,例如sbsigntoolsbverify
  • .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 OKSignature verification failed

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

相关内容