[SOLVED]Secure GRUB: Verification requested but nobody cares

[regox]

I am trying to enable Secure Boot on my system. I want to do this with my own keys, without using shim.
I use full-disk encryption, my /boot is unencrypted and resides on a separate partition, along with the EFI partition.
I followed Sakaki's Guide, this Funtoo Guide and this.

At this point, I have generated the necessary keys and enrolled them successfully in my firmware:

Code: Select all

sbkeysync --verbose
Filesystem keystore:
firmware keys:
  PK:
    /CN=thinkpad platform key
  KEK:
    /CN=thinkpad key-exchange-key
  db:
    /CN=thinkpad kernel-signing-key
  dbx:
filesystem keys:
  PK:
  KEK:
  db:
  dbx:
New keys in filesystem:

The GRUB image is signed with the correct key:

Code: Select all

sbverify --verbose --cert /etc/efikeys/db.crt /boot/EFI/gentoo/grubx64.efi
signature 1
image signature issuers:
 - /CN=thinkpad kernel-signing-key
image signature certificates:
 - subject: /CN=thinkpad kernel-signing-key
   issuer:  /CN=thinkpad kernel-signing-key
PKCS7 verification passed
Signature verification OK

When I boot the system (with Secure Boot enabled), the firmware loads GRUB and I see the GRUB menu as expected. This is why I think everything is correct up to this point.

Next, GRUB should verify the kernel and initramfs with a GPG signature. For this, I generated the appropriate key

Code: Select all

gpg --verbose --homedir=/mnt/grub /mnt/grub/grub.pub
pub   rsa3072 2022-03-19 [SC]
      65CFEB3B14BF520829563EAA5D8C9013801625B6
uid           grub2
sig        5D8C9013801625B6 2022-03-19   [selfsig]
sub   rsa3072 2022-03-19 [E]
sig        5D8C9013801625B6 2022-03-19   [keybind]

and used them to sign kernel + my initramfs. The signature looks good:

Code: Select all

gpg --verbose --homedir=/mnt/grub --verify /boot/vmlinuz-5.15.26-gentoo-x86_64.sig
gpg: assuming signed data in '/boot/vmlinuz-5.15.26-gentoo-x86_64'
gpg: Signature made Sa 19 Mär 2022 13:25:15 CET
gpg:                using RSA key 65CFEB3B14BF520829563EAA5D8C9013801625B6
gpg: using pgp trust model
gpg: Good signature from "grub2" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 65CF EB3B 14BF 5208 2956  3EAA 5D8C 9013 8016 25B6
gpg: binary signature, digest algorithm SHA256, key algorithm rsa3072

This public key is built into the GRUB image when I generate the image:

Code: Select all

grub-mkstandalone --directory /usr/lib/grub/x86_64-efi/ --format x86_64-efi --modules part_gpt fat ext2 configfile verify gcry_sha512 gcry_sha256 gcry_rsa password_pbkdf2 echo normal linux linuxefi all_video search search_fs_uuid reboot sleep loadenv minicmd test echo --pubkey /mnt/grub/grub.pub --disable-shim-lock --output /boot/EFI/gentoo/grubx64.efi /boot/grub/grub.cfg=/etc/default/grub-initial.cfg /boot/grub/grub.cfg.sig=/etc/default/grub-initial.cfg.sig

(I re-signed it after generation, I just checked again).
My grub-initial.cfg:

Code: Select all

set check_signatures=enforce
set check_signatures

set superusers="root"
export superusers
password_pbkdf2 root grub.pbkdf2.sha512.10000.XXXX-MY-PASSWORD-HASH-XXXX

set root=(memdisk)
set prefix=$(root)/grub
search --no-floppy --fs-uuid --set=root 7DF7-8065
configfile /grub/grub.cfg

echo grub.cfg did not boot the system but returned to initial.cfg.
echo Exiting in 10 seconds.
sleep 10
exit

The "normal" /boot/grub/grub.cfg as well as the initial GRUB config are also signed with GPG.
The menu entry that GRUB shows is defined in /boot/grub/grub.cfg:

Code: Select all

menuentry 'Gentoo GNU/Linux' --unrestricted --class gentoo --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-dd25cec6-beaa-4109-ab6b-e3e80e37f317' {
	load_video
	if [ "x$grub_platform" = xefi ]; then
		set gfxpayload=keep
	fi
	insmod gzio
	insmod part_gpt
	insmod fat
	search --no-floppy --fs-uuid --set=root 7DF7-8065
	echo	'Loading Linux 5.15.26-gentoo-x86_64 ...'
	linux	/vmlinuz-5.15.26-gentoo-x86_64 root=/dev/mapper/volgroup-root ro dolvm crypt_root=UUID=0a094fef-7708-41c2-8e96-649bfc5a2637 keymap=de quiet 
	echo	'Loading initial ramdisk ...'
	initrd	/custom-initramfs-5.15.26-gentoo.cpio.gz
}

And this is where the error occurs (when Secure Boot is enabled): GRUB starts normally, I select this entry and it then fails with something like:

Code: Select all

Loading Linux 5.15.26-gentoo-x86_64 ...
error: Verification requested but nobody cares

This error does not occur if I have Secure Boot disabled. In that case, I can normally select this entry and the initrd starts. I don't find this error message particularly helpful and I don't really know what I'm doing wrong. What does it mean exactly?
I checked online if others have had similar problems, but most of the time people were using the "normal" GRUB image with the modules not built in (instead of grub-mkstandalone), but I think I do that correctly.

Any hints are appreciated. Thank you in advance.

Cheers,

regox

[GDH-gentoo]

Code: Select all

error: Verification requested but nobody cares

It looks like this message is printed by GRUB, but it should be followed by the name of a file. Is it?

[regox]

Thanks for your reply.

Code: Select all

error: Verification requested but nobody cares

It looks like this message is printed by GRUB, but it should be followed by the name of a file. Is it?

Yes, I just checked again, the exact message is:

Code: Select all

error: verification requested but nobody cares: /vmlinuz-5.15.26-gentoo-x86_64.

I also added some debug flags to GRUB with debug=linux,loader,verify. That gives me this:

Code: Select all

Booting `Gentoo GNU/Linux'

kern/verifiers.c:212: string: insmod gzio, type: 2
kern/verifiers.c:212: string: insmod part_gpt, type: 2
kern/verifiers.c:212: string: insmod fat, type: 2
kern/verifiers.c:212: string: search --no-floppy --fs-uuid --set=root 7DF7-8065, type: 2
kern/verifiers.c:212: string: echo Loading Linux 5.15.26-gentoo-x86_64 ..., type: 2
Loading Linux 5.15.26-gentoo-x86_64 ...
kern/verifiers.c:212: string: linux /vmlinuz-5.15.26-gentoo-x86_64 root=/dev/mapper/volgroup-root ro dolvm
crypt_root=UUID=0a094fef-7708-41c2-8e96-649bfc5a2637 keymap=de quiet, type: 2
kern/verifiers.c:88: file: (memdisk)/boot/grub/x86_64-efi/linux.mod type: 1
kern/verifiers.c:88: file: (memdisk)/boot/grub/x86_64-efi/relocator.mod type: 1
kern/verifiers.c:88: file: (memdisk)/boot/grub/x86_64-efi/mmap.mod type: 1
kern/verifiers.c:88: file: /vmlinuz-5.15.26-gentoo-x86_64 type: 3
error: verification requested but nobody cares: /vmlinuz-5.15.26-gentoo-x86_64.
kern/verifiers.c:212: string: echo Loading initial ramdisk ..., type: 2
Loading initial ramdisk ...
kern/verifiers.c:212: string: initrd /custom-initramfs-5.15.26-gentoo.cpio.gz, type: 2
error: you need to load the kernel first.

I can't have debug=all because that will flood the output with malloc and fs messages. But if anyone has a suggestion for different debug flags, I'm open for it.

[regox]

Btw, I looked for the error message in the sources of GRUB at https://git.savannah.gnu.org/git/grub.git. In file grub/grub-core/kern/verifiers.c

Code: Select all

  if (!ver)
    {
      if (defer)
	{
	  grub_error (GRUB_ERR_ACCESS_DENIED,
		      N_("verification requested but nobody cares: %s"), io->name);
	  goto fail_noclose;
	}

      /* No verifiers wanted to verify. Just return underlying file. */
      return io;

So as far as I understand the (GPG?) "verifier" is not working correctly.

[GDH-gentoo]

Btw, I looked for the error message in the sources of GRUB at https://git.savannah.gnu.org/git/grub.git. In file grub/grub-core/kern/verifiers.c

Code: Select all

  if (!ver)
    {
      if (defer)
	{
	  grub_error (GRUB_ERR_ACCESS_DENIED,
		      N_("verification requested but nobody cares: %s"), io->name);
	  goto fail_noclose;
	}

      /* No verifiers wanted to verify. Just return underlying file. */
      return io;

Yes, that's the code fragment I was looking at. Whith more context:

grub-core/kern/verifiers.c

Code: Select all

  FOR_LIST_ELEMENTS(ver, grub_file_verifiers)
    {
      enum grub_verify_flags flags = 0;
      err = ver->init (io, type, &context, &flags);
      if (err)
        goto fail_noclose;
      if (flags & GRUB_VERIFY_FLAGS_DEFER_AUTH)
        {
          defer = 1;
          continue;
        }
      if (!(flags & GRUB_VERIFY_FLAGS_SKIP_VERIFICATION))
        break;
    }

  if (!ver)
    {
      if (defer)
        {
          grub_error (GRUB_ERR_ACCESS_DENIED,
                      N_("verification requested but nobody cares: %s"), io->name);
          goto fail_noclose;
        }

      /* No verifiers wanted to verify. Just return underlying file. */
      return io;
    }

GRUB 2.06 has three "verifiers": the lockdown verifier (purpose), the Shim lock verifier, and the PGP verifier. If I'm reading it correctly, the code iterates over all "registered" (with grub_verifier_register()) verifiers, calling their init() "method". The Shim lock verifier should not have been registered, because of the --disable-shim-lock option that you used, the lockdown verifier should be registered if secure boot is enabled, and the PGP verifier should be registered if the pgp module is loaded (which should be in your case, because module gcry_rsa depends on it).

Verifiers can decline performing verification by having their init() "method" set the GRUB_VERIFY_FLAGS_SKIP_VERIFICATION flag, and can defer to other verifiers for performing verification by having their init() "method" set the GRUB_VERIFY_FLAGS_DEFER_AUTH flag (explanation). For GRUB 2.06, it looks like the lockdown verifier is the only one that defers to other verifiers. AFAIK, if one verifier defers to other verifiers, but all other registered verifiers decline performing verification, you get the "verification requested but nobody cares" error, and the PGP verifier declines performing verification unless GRUB environment variable check_signatures is set to "enforce".

grub-core/commands/pgp.c

Code: Select all

static int sec = 0;

static grub_err_t
grub_pubkey_init (grub_file_t io, enum grub_file_type type __attribute__ ((unused)),
		  void **context, enum grub_verify_flags *flags)
{
  /* ... */
  if (!sec)
    {
      *flags = GRUB_VERIFY_FLAGS_SKIP_VERIFICATION;
      return GRUB_ERR_NONE;
    }
  /* ... */
}
/* ... */
static char *
grub_env_write_sec (struct grub_env_var *var __attribute__ ((unused)),
		    const char *val)
{
  sec = (*val == '1') || (*val == 'e');
  return grub_strdup (sec ? "enforce" : "no");
}
/* ... */
GRUB_MOD_INIT(pgp)
{
  const char *val;
  /* ... */

  val = grub_env_get ("check_signatures");
  if (val && (val[0] == '1' || val[0] == 'e'))
    sec = 1;
  else
    sec = 0;

  grub_register_variable_hook ("check_signatures", 0, grub_env_write_sec);
  grub_env_export ("check_signatures");
/* ... */
}

So as far as I understand the (GPG?) "verifier" is not working correctly.

That's what I'm thinking, so:

My grub-initial.cfg:

Code: Select all

set check_signatures=enforce
set check_signatures
...

Is the second set command a typo, or is it really written like that? Because GRUB should print an error if the '=' is not present.

[regox]

Thank you very much for your explanation. I think I have a better understanding of the whole concept now.

That's what I'm thinking, so:

My grub-initial.cfg:

Code: Select all

set check_signatures=enforce
set check_signatures
...

Is the second set command a typo, or is it really written like that? Because GRUB should print an error if the '=' is not present.

You're right, that was actually a mistake in my grub-inital.cfg. The error shows so quickly that you barely notice it, because it continues to GRUB menu anyway. But with an additional sleep command I was able to see it.
I corrected it to

Code: Select all

set check_signatures=enforce
export check_signatures
...

But unfortunately, I am still getting the same behavior.

[regox]

I have noticed some interesting behavior: In the menuentry in my /boot/grub/grub.cfg I added "list_trusted", because I wanted to see if the key is stored correctly. I also added the check_signatures here again, just to be sure, but this alone made no difference as expected.

Code: Select all

...
set debug=crypt,linux,loader,verify
set check_signatures=enforce
echo 'List trusted:'
list_trusted
insmod gzio
insmod part_gpt
insmod fat
search --no-floppy --fs-uuid --set=root 7DF7-8065
echo	'Loading Linux 5.15.26-gentoo-x86_64 ...'
linux	/vmlinuz-5.15.26-gentoo-x86_64 root=/dev/mapper/volgroup-root ro dolvm crypt_root=UUID=0a094fef-7708-41c2-8e96-649bfc5a2637 keymap=de quiet 
echo	'Loading initial ramdisk ...'
initrd	/custom-initramfs-5.15.26-gentoo.cpio.gz
...

Now, GRUB will actually show a different error:

Code: Select all

...
kern/verifiers.c:212: string: search --no-floppy --fs-uuid --set=root 7DF7-8065, type: 2
kern/verifiers.c:212: string: echo Loading Linux 5.15.26-gentoo-x86_64 ..., type: 2
Loading Linux 5.15.26-gentoo-x86_64 ...
kern/verifiers.c:212: string: linux /vmlinuz-5.15.26-gentoo-x86_64 root=/dev/mapper/volgroup-root ro dolvm
crypt_root=UUID=0a094fef-7708-41c2-8e96-649bfc5a2637 keymap=de quiet, type: 2 
kern/verifiers.c:88: file: /vmlinuz-5.15.26-gentoo-x86_64 type: 3 
kern/verifiers.c:88: file: /vmlinuz-5.15.26-gentoo-x86_64.sig type: 30
commands/pgp.c:496: alive
commands/pgp.c:593: alive
commands/pgp.c:602: @ 34
commands/pgp.c:608: alive
commands/pgp.c:611: alive
commands/pgp.c:613: l = 0x0c00
commands/pgp.c:616: alive
commands/pgp.c:619: alive
commands/pgp.c:621: alive
commands/pgp.c:626: alive
error: public key b625168013908c5d not found.
kern/verifiers.c:212: string: echo Loading initial ramdisk ..., type: 2
Loading initial ramdisk ...
kern/verifiers.c:212: string: initrd /custom-initramfs-5.15.26-gentoo.cpio.gz, type: 2
error: you need to load the kernel first.

I am a bit confused why list_trusted would make the kernel loading fail with a different error. It looks like the kernel signature is now actually being loaded. At first sight it also looks like the expected key is not the right one, but actually the bytes are just in reverse order for some reason. If you check with my post above, it matches with the public key I intended to use. Nevertheless, it seems like that it is not included in the GRUB image correctly, although grub-mkstandalone (same as above with --verbose) did not give any errors when I created the image:

Code: Select all

grub-mkstandalone ... | grep "public key"
grub-mkstandalone: info: the size of public key 0 is 0x6b8.

[GDH-gentoo]

If you check with my post above, it matches with the public key I intended to use. Nevertheless, it seems like that it is not included in the GRUB image correctly [...]

I'd do a little experiment. Remove the setting of check_signatures in your /etc/default/grub-initial.cfg file. GRUB should set it automatically to "enforce" if a public key was passed with the --pubkey option. Then, when the menu is showing, drop to GRUB's command-line interface by pressing 'c', and check with:

Code: Select all

grub> set debug=crypt,verify
grub> echo $check_signatures
grub> list_trusted

If everything looks correct, try verifying the kernel manually:

Code: Select all

grub> search --no-floppy --fs-uuid --set=root 7DF7-8065
grub> verify_detached /vmlinuz-5.15.26-gentoo-x86_64 /vmlinuz-5.15.26-gentoo-x86_64.sig

And see what happens.

[Goverp]

I happened across this post on the grub help forums that I think explains what's going on.

[regox]

If you check with my post above, it matches with the public key I intended to use. Nevertheless, it seems like that it is not included in the GRUB image correctly [...]

I'd do a little experiment. Remove the setting of check_signatures in your /etc/default/grub-initial.cfg file. GRUB should set it automatically to "enforce" if a public key was passed with the --pubkey option. Then, when the menu is showing, drop to GRUB's command-line interface by pressing 'c', and check with:

Code: Select all

grub> set debug=crypt,verify
grub> echo $check_signatures
grub> list_trusted

If everything looks correct, try verifying the kernel manually:

Code: Select all

grub> search --no-floppy --fs-uuid --set=root 7DF7-8065
grub> verify_detached /vmlinuz-5.15.26-gentoo-x86_64 /vmlinuz-5.15.26-gentoo-x86_64.sig

And see what happens.

Okay, I did what you suggested:

Code: Select all

grub> set debug=crypt,verify
grub> echo $check_signatures
kern/verifiers.c:212: string: echo, type 2

grub> list_trusted
kern/verifiers.c:212: string: list_trusted, type 2
kern/verifiers.c:88: file: (memdisk)/boot/grub/x86_64-efi/pgp.mod type: 1
kern/verifiers.c:88: file: (memdisk)/boot/grub/x86_64-efi/mpi.mod type: 1
kern/verifiers.c:88: file: (memdisk)/boot/grub/x86_64-efi/gcry_sha1.mod type: 1
grub> echo $check_signatures
kern/verifiers.c:212: string: echo no, type 2
no
grub> set check_signatures=enforce
kern/verifiers.c:212: string: set check_signatures=enforce, type: 2
grub> list_trusted
kern/verifiers.c:212: string: list_trusted, type 2
grub> search --no-floppy --fs-uuid --set=root 7DF7-8065
kern/verifiers.c:212: string: search --no-floppy --fs-uuid --set=root 7DF7-8065, type 2
grub> verify_detached /vmlinuz-5.15.26-gentoo-x86_64 /vmlinuz-5.15.26-gentoo-x86_64.sig
kern/verifiers.c:212: string: verify_detached /vmlinuz-5.15.26-gentoo-x86_64 /vmlinuz-5.15.26-gentoo-x86_64.sig, type 2
commands/pgp.c:823: alive
commands/pgp.c:828: alive
kern/verifiers.c:88: file:  /vmlinuz-5.15.26-gentoo-x86_64  type: 59
kern/verifiers.c:88: file:  /vmlinuz-5.15.26-gentoo-x86_64.sig  type: 131102
kern/verifiers.c:88: file: (memdisk)/boot/grub/x86_64-efi/gcry_sha1.mod type: 1
commands/pgp.c:496: alive
commands/pgp.c:593: alive
commands/pgp.c:602: @ 34
commands/pgp.c:608: alive
commands/pgp.c:611: alive
commands/pgp.c:613: l = 0x0c00
commands/pgp.c:616: alive
commands/pgp.c:619: alive
commands/pgp.c:621: alive
commands/pgp.c:626: alive 
error: public key b625168013908c5d not found.

Strange that the check_signatures variable is not set automatically. It should be implicitly set by using --pubkey as you and the documentation say. So maybe grub-mkimage/grub-mkstandalone has a problem with my public key, hence why it is not including it in the GRUB image and also not setting check_signatures.

Btw, this is how grub-mkstandalone invokes grub-mkimage:

Code: Select all

grub-mkstandalone ... | grep "grub-mkimage"
grub-mkstandalone: info: grub-mkimage --directory '/usr/lib/grub/x86_64-efi/' --prefix '(memdisk)/boot/grub' --output '/boot/EFI/gentoo/grubx64.efi'  --dtb '' --sbat '' --format 'x86_64-efi' --compression 'auto'  --disable-shim-lock --memdisk '/tmp/grub.mAy0Om' --pubkey '/mnt/grub/grub.pub' 'part_gpt' 'memdisk' 'tar'

[regox]

I happened across this post on the grub help forums that I think explains what's going on.

Thanks for your reply.

As far as I understood I embed all modules in the image because I use grub-mkstandalone, therefore I should not have this problem.

[GDH-gentoo]

So maybe grub-mkimage/grub-mkstandalone has a problem with my public key, hence why it is not including it in the GRUB image and also not setting check_signatures.

Yes, it looks like the public key is somehow not actually embedded in grubx64.efi despite having specified --pubkey, which would be consistent with list_trusted returning an empty list, and ckeck_signatures being automatically set to "no".

Next thing I would try from GRUB's command-line interface is loading the public key manually as a test. That requires putting file grub.pub somewhere accessible, like e.g. the directory of your kernel:

Code: Select all

grub> set debug=crypt,verify
grub> search --no-floppy --fs-uuid --set=root 7DF7-8065
grub> trust --skip-sig /grub.pub
grub> list_trusted

If the public key gets added to the trusted public key list, try verifying the kernel:

Code: Select all

grub> set check_signatures=enforce
grub> verify_detached /vmlinuz-5.15.26-gentoo-x86_64 /vmlinuz-5.15.26-gentoo-x86_64.sig

As far as I understood I embed all modules in the image because I use grub-mkstandalone, therefore I should not have this problem.

That's my understanding as well, and is consistent with the debug output showing module pathnames that start with "(memdisk)".

[regox]

Next thing I would try from GRUB's command-line interface is loading the public key manually as a test. That requires putting file grub.pub somewhere accessible, like e.g. the directory of your kernel:

Code: Select all

grub> set debug=crypt,verify
grub> search --no-floppy --fs-uuid --set=root 7DF7-8065
grub> trust --skip-sig /grub.pub
grub> list_trusted

If the public key gets added to the trusted public key list, try verifying the kernel:

Code: Select all

grub> set check_signatures=enforce
grub> verify_detached /vmlinuz-5.15.26-gentoo-x86_64 /vmlinuz-5.15.26-gentoo-x86_64.sig

As far as I understood I embed all modules in the image because I use grub-mkstandalone, therefore I should not have this problem.

That's my understanding as well, and is consistent with the debug output showing module pathnames that start with "(memdisk)".

Thank you very much for your help. I could successfully boot with Secure boot enabled for the first time.

Code: Select all

dmesg | grep "Secure boot"
[    0.019106] Secure boot enabled

list_trusted returned something. verify-detached did not return anything, so I was not sure if it was working correctly,
so I put it directly in grub.cfg:

Code: Select all

menuentry 'Gentoo GNU/Linux' --unrestricted --class gentoo --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-dd25cec6-beaa-4109-ab6b-e3e80e37f317' {
	load_video
	if [ "x$grub_platform" = xefi ]; then
		set gfxpayload=keep
	fi
	insmod gzio
	insmod part_gpt
	insmod fat
	trust --skip-sig '(hd0,gpt1)/grub/grub.pub'
	set check_signatures=enforce
	list_trusted
	search --no-floppy --fs-uuid --set=root 7DF7-8065
	echo	'Loading Linux 5.15.26-gentoo-x86_64 ...'
	linux	/vmlinuz-5.15.26-gentoo-x86_64 root=/dev/mapper/volgroup-root ro dolvm crypt_root=UUID=0a094fef-7708-41c2-8e96-649bfc5a2637 keymap=de quiet 
	echo	'Loading initial ramdisk ...'
	initrd	/custom-initramfs-5.15.26-gentoo.cpio.gz
}

which now seems to work.
So at least we now know that my public key is not broken and GRUB can actually make use of it. This confirms that the problem is that the key is somehow not embedded in the image.
Would there be any problems if I permanently load the key this way?

[regox]

Would there be any problems if I permanently load the key this way?

If I think about it, it wouldn't make much sense to do it this way permanently, because now anyone could use their own key, sign their malicious image and put their public key in /boot/grub/grub.pub for GRUB to load it. The whole point of embedding it in the GRUB image was so that the whole thing could be signed and checked by the firmware, right?

[GDH-gentoo]

The whole point of embedding it in the GRUB image was so that the whole thing could be signed and checked by the firmware, right?

Exactly. As GRUB's manual says, "it is expected that --skip-sig is useful for testing and manual booting". trust without --skip-sig can be used to load additional signed public keys, but you can't verify them if you don't have any trusted public key to begin with.

[regox]

I now know that the problem is that GRUB does not add the public key from the image to its trust store. The key is actually there in the image (twice actually):

Code: Select all

hexdump -C /mnt/grub/grub.pub | head -n 30
00000000  99 01 8d 04 62 35 b2 aa  01 0c 00 a2 54 65 12 7b  |....b5......Te.{|
00000010  9c 50 bf e7 05 7b 78 83  e2 e5 eb 28 95 4b d1 7d  |.P...{x....(.K.}|
00000020  81 58 8c 1c 4c 04 61 d6  28 62 76 07 9d a5 ba 48  |.X..L.a.(bv....H|
00000030  ed a3 67 bc 38 ad 1e c9  bd 00 f3 7b b4 4f ad a5  |..g.8......{.O..|
00000040  95 8b 62 00 03 14 f8 41  b5 d9 a0 37 75 15 ba 97  |..b....A...7u...|
00000050  4e fa 66 39 3f 99 b4 55  9c dd 31 3e b8 c1 d7 ab  |N.f9?..U..1>....|
00000060  bb 46 70 37 60 94 c1 80  cf 8f 3d 2f 02 7f 1d 26  |.Fp7`.....=/...&|
...

Code: Select all

hexdump -C EFI/gentoo/grubx64.efi | grep -A 30 "b5......Te.{"
0001fcc0  99 01 8d 04 62 35 b2 aa  01 0c 00 a2 54 65 12 7b  |....b5......Te.{|
0001fcd0  9c 50 bf e7 05 7b 78 83  e2 e5 eb 28 95 4b d1 7d  |.P...{x....(.K.}|
0001fce0  81 58 8c 1c 4c 04 61 d6  28 62 76 07 9d a5 ba 48  |.X..L.a.(bv....H|
0001fcf0  ed a3 67 bc 38 ad 1e c9  bd 00 f3 7b b4 4f ad a5  |..g.8......{.O..|
0001fd00  95 8b 62 00 03 14 f8 41  b5 d9 a0 37 75 15 ba 97  |..b....A...7u...|
0001fd10  4e fa 66 39 3f 99 b4 55  9c dd 31 3e b8 c1 d7 ab  |N.f9?..U..1>....|
0001fd20  bb 46 70 37 60 94 c1 80  cf 8f 3d 2f 02 7f 1d 26  |.Fp7`.....=/...&|
...
00c45d80  99 01 8d 04 62 35 b2 aa  01 0c 00 a2 54 65 12 7b  |....b5......Te.{|
00c45d90  9c 50 bf e7 05 7b 78 83  e2 e5 eb 28 95 4b d1 7d  |.P...{x....(.K.}|
00c45da0  81 58 8c 1c 4c 04 61 d6  28 62 76 07 9d a5 ba 48  |.X..L.a.(bv....H|
00c45db0  ed a3 67 bc 38 ad 1e c9  bd 00 f3 7b b4 4f ad a5  |..g.8......{.O..|
00c45dc0  95 8b 62 00 03 14 f8 41  b5 d9 a0 37 75 15 ba 97  |..b....A...7u...|
00c45dd0  4e fa 66 39 3f 99 b4 55  9c dd 31 3e b8 c1 d7 ab  |N.f9?..U..1>....|
00c45de0  bb 46 70 37 60 94 c1 80  cf 8f 3d 2f 02 7f 1d 26  |.Fp7`.....=/...&|
...

So, has anyone an idea why GRUB does not automatically "trust" the key?

[regox]

Okay, so I was finally able to fix this issue, thanks to the help of the grub-help mailing list.

TL;DR: I was missing the pgp module.

If I understood correctly, the key is added by the init function of the pgp module. This init function iterates over modules embedded in the grub image (the public key is represented as a "module" of a specific type). These modules are only available during image
initialization; when it's completed, modules are discarded (depending on platform, memory can be reused). To use a public key embedded in grub image you must also embed the pgp module itself. As soon as you use grub-mkimage with --pubkey, you have to
add the pgp module, as otherwise the key is not being used at all.

So If anyone comes across this looking for a solution, this is my final and working signing process:

Code: Select all

#!/bin/bash

for image in /boot/vmlinuz-*-x86_64 /boot/custom-initramfs*.gz
do
	modified=`date -r $image`
	read -p "Do you want to sign $image, last modified on $modified? (y/n)" yn
	case $yn in
		[yY] ) gpg --verbose --homedir=/mnt/grub --pinentry-mode=ask -b $image || exit;;
		*    ) echo "Skipping $image"	
esac
done

echo "Generating GRUB image..."
grub-mkstandalone --pubkey "/mnt/grub/grub.pub" --directory "/usr/lib/grub/x86_64-efi" --format "x86_64-efi" --modules "pgp part_gpt fat ext2 configfile gcry_sha256 gcry_rsa password_pbkdf2 normal linux all_video search search_fs_uuid reboot sleep loadenv minicmd test echo font" --disable-shim-lock --output "/boot/EFI/gentoo/grubx64.efi" "/boot/grub/grub.cfg=/etc/default/grub-initial.cfg" "/boot/grub/grub.cfg.sig=/etc/default/grub-initial.cfg.sig" || exit

read -p "Do you want to sign /boot/EFI/gentoo/grubx64.efi? (y/n)" yn
case $yn in
	[yY] ) sbsign --key /mnt/efikeys/db.key --cert /etc/efikeys/db.crt -o /boot/EFI/gentoo/grubx64.efi /boot/EFI/gentoo/grubx64.efi;;
		 * ) echo "NOT signing GRUB image, Secure boot will NOT work!"
esac

Have a good one,

regox

[1ng0]

Okay, so I was finally able to fix this issue, thanks to the help of the grub-help mailing list.

TL;DR: I was missing the pgp module.

I stumbled across this thread when looking for an implementation of grub with secure boot on Arch Linux. When trying to sign all associated files in the hope to get rid of 'prohibited by Secure Boot policy' (which doesn't work sadly).

Just for anyone passing by in the future, I saw the same effect with gnupg 2.4.5 and grub 2.12 when gpg --gen-key creates an ed25519 key by default which is silently ignored by grub (or the pgp module) when passing it with the --pubkey flag - took a while to figure this one out Make sure to use gpg --full-gen-key and select to create an RSA key.

Best whishes!