☰

UEFI SHIM 错误“verify_buffer() 未找到签名”

tag-icon • tag-icon linux uefi secure-boot
UEFI SHIM 错误“verify_buffer() 未找到签名”

继续从UEFI 自签名内核从 Microsoft 签名操作系统加载程序加载我用了https://github.com/rhboot/shim/releases/tag/15.4并在我的本地计算机上构建（Ubuntu 18.04 LTS）

openssl req -new -x509 -newkey rsa:2048 -keyout MOK.key -out MOK.crt -nodes -days 3650 -subj "/CN=Your Name/"
openssl x509 -in MOK.crt -out MOK.cer -outform DER

编译源代码以使用 SHIM 密钥 (MOK.cer)

make VENDOR_CERT_FILE=MOK.cer

签署了我的测试二进制文件（重命名为 grubx64.efi），仅在控制台上打印“Hello World”。

sbsign --key MOK.key --cert MOK.crt --output grubx64.efi  test.efi

使用 objdump 工具，我可以在签名的 grubx64.efi 中看到有效的 SecureDir 部分。

objdump -x grubx64.efi

我还使用 sbverify 验证了签名。

sbverify --list grubx64.efi

现在，当我在 SecureBoot 下运行 SHIM 时，当 SHIM 尝试加载 SHIM 密钥签名的 grubx64.efi 时，我收到以下错误

pe.c:857:handle_sbat() SBAT section data
pe.c:865:handle_sbat() sbat, 1, SBAT Version, sbat, 1, https://github.com/rhboot/shim/blob/main/SBAT.md
pe.c:865:handle_sbat() shim, 1, UEFI shim, shim, 1, https://github.com/rhboot/shim
sbat.c:121:verify_single_entry() component sbat has a matching SBAT variable entry, verifying
sbat.c:182:verify_sbat_helper() finished verifying SBAT data: Success
pe.c:574:generate_hash() sha1 authenticode hash:
pe.c:575:generate_hash() 00000000  XX XX XX XX XX XX XX XX  XX XX XX XX 09 aa c7 09  XXXXXXXXXXXX|....|
pe.c:575:generate_hash() 00000004  1e 6b c6 68 88 a9 e5 88  72 fd 81 08 32 15 2e 24  |.k.h....r...2..$|
pe.c:576:generate_hash() sha256 authenticode hash:
pe.c:577:generate_hash() 00000000  08 16 c3 bd 93 91 a5 0f  3a b4 24 a1 b1 97 5c ee  |........:.$...\.|
pe.c:577:generate_hash() 00000010  47 33 76 37 7f 71 cc b0  c9 82 e0 ac 50 49 0d 0e  |G3v7.q......PI..|
shim.c:630:verify_buffer() check_allowlist: Not Found
shim.c:644:verify_buffer() No signatures found
Verification failed: Security Policy Violation
Failed to load image: Security Policy Violation
shim.c:378 check_allowlist() check_db_hash(db, sha256hash) != DATA_FOUND
shim.c:386 check_allowlist() check_db_hash(db, sha1hash) != DATA_FOUND
shim.c:430 check_allowlist() check_db_hash(MokList, sha256hash) != DATA_FOUND
shim.c:629 verify_buffer() check_allowlist(): Not Found
shim.c:1188 start_image() Failed to load image: Security Policy Violation
start_image() returned Security Policy Violation
Exit status code: Security Violation

任何想法？

答案1

要诊断，您可能需要操作系统级mokutil工具。

如果运行mokutil --list-enrolled，您是否会获得 MOK.cer 的证书信息（输出类似于openssl x509 -in MOK.crt -noout -text）？如果没有，那么您的 MOK 尚未正确注册。错误列表中的这些行表明可能是原因：

shim.c:630:verify_buffer() check_allowlist: Not Found

shim.c:430 check_allowlist() check_db_hash(MokList, sha256hash) != DATA_FOUND

换句话说，名为的 UEFI NVRAM 变量MokList不存在或不包含 MOK 证书。

对于 MOK，MokList将创建一个新的 UEFI NVRAM 变量，并以只能在启动时直接访问的方式对其进行保护（通过shimx64.efi和/或mmx64.efi）。这也意味着您将无法直接通过该/sys/firmware/efi/efivars/MokList-605dab50-e046-4300-abb6-3dd810dd8b23文件检查它，因为这样的文件不存在。

内容的第二个副本应该位于 UEFI 变量中MokListRT，运行的操作系统可以访问该变量（如/sys/firmware/efi/efivars/MokListRT-605dab50-e046-4300-abb6-3dd810dd8b23在 Linux 中），并且根本不会永久存储在 NVRAM 中：shimx64.efi每次启动时都会进行复制，因此如果操作系统MokListRT已从固件并且它具有正确的内容（如所示mokutil --list-enrolled），您可以确信垫片具有可用的 MOK。

由于 MOK 存储涉及 UEFI NVRAM 变量，因此不幸的是它会受到 UEFI 固件错误和实现怪癖的影响。有时，NVRAM 变量存储也可以通过固件升级或“BIOS 设置”恢复出厂设置（更正确的说法是UEFI 固件设置，但旧名称似乎仍然存在）。

您可能需要提及您正在使用的系统/主板的名称：如果它存在有关安全启动和/或 UEFI NVRAM 变量的已知问题，并且其他人已经找到了解决方法，他们也许能够为您提供帮助。

相关内容