UEFI SHIM Error "verify_buffer() No signatures found"

Question

Continuing from UEFI Self-Signed Kernel loading from a Microsoft Signed OS Loader I used https://github.com/rhboot/shim/releases/tag/15.4 and built on my local machine (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

Complied source code to use SHIM Keys (MOK.cer)

make VENDOR_CERT_FILE=MOK.cer

Signed my test binary(renamed as grubx64.efi) with which just prints "Hello World" on console.

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

Using tool objdump, I could see valid SecureDir section in the signed grubx64.efi.

objdump -x grubx64.efi

I also verified signature using sbverify.

sbverify --list grubx64.efi

Now, when I run the SHIM under SecureBoot, I get following error when SHIM is trying to load SHIM Keys signed 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

Any idea?

Answer 1

To diagnose, you might need the OS-level mokutil tool.

If you run mokutil --list-enrolled, do you get the certificate information of your MOK.cer (output similar to openssl x509 -in MOK.crt -noout -text)? If not, then your MOK is not properly registered yet. These lines in your error listing suggests that might be the reason:

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

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

In other words, a UEFI NVRAM variable named MokList either does not exist or does not contain the MOK certificate.

For the MOK, a new UEFI NVRAM variable MokList is created, and protected in such a way that it is directly accessible only at boot time (by the shimx64.efi and/or mmx64.efi). This also means you won't be able to examine it directly via the /sys/firmware/efi/efivars/MokList-605dab50-e046-4300-abb6-3dd810dd8b23 file, as such a file won't exist.

A second copy of the contents should be at UEFI variable MokListRT, which is accessible to the running OS (as /sys/firmware/efi/efivars/MokListRT-605dab50-e046-4300-abb6-3dd810dd8b23 in Linux) and not persistently stored in NVRAM at all: shimx64.efi does the copying at every boot, so if the OS has received the MokListRT variable from the firmware and it has correct contents (as displayed by mokutil --list-enrolled), you can be confident that the shim has the MOK available to it.

Since the MOK storage involves UEFI NVRAM variables, it is unfortunately subject to UEFI firmware bugs and implementation quirks. Sometimes the NVRAM variable storage can also be wiped by a firmware upgrade or a factory reset of "BIOS settings" (more properly UEFI firmware settings, but the old name seems to live on).

You might want to mention the name of the system/motherboard you're using: if it has known issues regarding Secure Boot and/or UEFI NVRAM variables, and someone else has figured out a workaround, they might be able to help you.