Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[SOLVED]Secure GRUB: Verification requested but nobody cares
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo
View previous topic :: View next topic  
Author Message
regox
Tux's lil' helper
Tux's lil' helper


Joined: 12 Sep 2021
Posts: 79

PostPosted: Sat Mar 19, 2022 2:57 pm    Post subject: [SOLVED]Secure GRUB: Verification requested but nobody cares Reply with quote

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:

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:

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:

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:

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:

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:

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:

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:

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


Last edited by regox on Sun Mar 27, 2022 9:54 pm; edited 1 time in total
Back to top
View user's profile Send private message
GDH-gentoo
Veteran
Veteran


Joined: 20 Jul 2019
Posts: 1541
Location: South America

PostPosted: Sat Mar 19, 2022 10:43 pm    Post subject: Re: Reply with quote

regox wrote:
Code:
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?
Back to top
View user's profile Send private message
regox
Tux's lil' helper
Tux's lil' helper


Joined: 12 Sep 2021
Posts: 79

PostPosted: Sun Mar 20, 2022 12:10 pm    Post subject: Re: Reply with quote

Thanks for your reply.

GDH-gentoo wrote:
regox wrote:
Code:
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:

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:

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.
Back to top
View user's profile Send private message
regox
Tux's lil' helper
Tux's lil' helper


Joined: 12 Sep 2021
Posts: 79

PostPosted: Sun Mar 20, 2022 12:19 pm    Post subject: Reply with quote

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:

  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.
Back to top
View user's profile Send private message
GDH-gentoo
Veteran
Veteran


Joined: 20 Jul 2019
Posts: 1541
Location: South America

PostPosted: Sun Mar 20, 2022 3:12 pm    Post subject: Reply with quote

regox wrote:
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:

  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:
  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:
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");
/* ... */
}
regox wrote:
So as far as I understand the (GPG?) "verifier" is not working correctly.
That's what I'm thinking, so:

regox wrote:
My grub-initial.cfg:
Code:

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.

Last edited by GDH-gentoo on Mon Mar 21, 2022 10:01 pm; edited 1 time in total
Back to top
View user's profile Send private message
regox
Tux's lil' helper
Tux's lil' helper


Joined: 12 Sep 2021
Posts: 79

PostPosted: Sun Mar 20, 2022 4:33 pm    Post subject: Reply with quote

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

GDH-gentoo wrote:
That's what I'm thinking, so:

regox wrote:
My grub-initial.cfg:
Code:

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:

set check_signatures=enforce
export check_signatures
...

But unfortunately, I am still getting the same behavior.
Back to top
View user's profile Send private message
regox
Tux's lil' helper
Tux's lil' helper


Joined: 12 Sep 2021
Posts: 79

PostPosted: Sun Mar 20, 2022 5:41 pm    Post subject: Reply with quote

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:

...
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:

...
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:

grub-mkstandalone ... | grep "public key"
grub-mkstandalone: info: the size of public key 0 is 0x6b8.
Back to top
View user's profile Send private message
GDH-gentoo
Veteran
Veteran


Joined: 20 Jul 2019
Posts: 1541
Location: South America

PostPosted: Sun Mar 20, 2022 8:56 pm    Post subject: Reply with quote

regox wrote:
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:
grub> set debug=crypt,verify
grub> echo $check_signatures
grub> list_trusted

If everything looks correct, try verifying the kernel manually:
Code:
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.
Back to top
View user's profile Send private message
Goverp
Advocate
Advocate


Joined: 07 Mar 2007
Posts: 2009

PostPosted: Sun Mar 20, 2022 11:37 pm    Post subject: Reply with quote

I happened across this post on the grub help forums that I think explains what's going on.
_________________
Greybeard
Back to top
View user's profile Send private message
regox
Tux's lil' helper
Tux's lil' helper


Joined: 12 Sep 2021
Posts: 79

PostPosted: Mon Mar 21, 2022 1:39 am    Post subject: Reply with quote

GDH-gentoo wrote:
regox wrote:
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:
grub> set debug=crypt,verify
grub> echo $check_signatures
grub> list_trusted

If everything looks correct, try verifying the kernel manually:
Code:
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:

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:

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'
Back to top
View user's profile Send private message
regox
Tux's lil' helper
Tux's lil' helper


Joined: 12 Sep 2021
Posts: 79

PostPosted: Mon Mar 21, 2022 1:41 am    Post subject: Reply with quote

Goverp wrote:
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.
Back to top
View user's profile Send private message
GDH-gentoo
Veteran
Veteran


Joined: 20 Jul 2019
Posts: 1541
Location: South America

PostPosted: Mon Mar 21, 2022 1:40 pm    Post subject: Reply with quote

regox wrote:
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:
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:
grub> set check_signatures=enforce
grub> verify_detached /vmlinuz-5.15.26-gentoo-x86_64 /vmlinuz-5.15.26-gentoo-x86_64.sig

regox wrote:
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)".
Back to top
View user's profile Send private message
regox
Tux's lil' helper
Tux's lil' helper


Joined: 12 Sep 2021
Posts: 79

PostPosted: Mon Mar 21, 2022 8:00 pm    Post subject: Reply with quote

GDH-gentoo wrote:
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:
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:
grub> set check_signatures=enforce
grub> verify_detached /vmlinuz-5.15.26-gentoo-x86_64 /vmlinuz-5.15.26-gentoo-x86_64.sig

regox wrote:
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:

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:

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?
Back to top
View user's profile Send private message
regox
Tux's lil' helper
Tux's lil' helper


Joined: 12 Sep 2021
Posts: 79

PostPosted: Mon Mar 21, 2022 9:11 pm    Post subject: Reply with quote

regox wrote:

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?
Back to top
View user's profile Send private message
GDH-gentoo
Veteran
Veteran


Joined: 20 Jul 2019
Posts: 1541
Location: South America

PostPosted: Mon Mar 21, 2022 9:45 pm    Post subject: Reply with quote

regox wrote:
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.
Back to top
View user's profile Send private message
regox
Tux's lil' helper
Tux's lil' helper


Joined: 12 Sep 2021
Posts: 79

PostPosted: Tue Mar 22, 2022 8:41 pm    Post subject: Reply with quote

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:

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:

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?
Back to top
View user's profile Send private message
regox
Tux's lil' helper
Tux's lil' helper


Joined: 12 Sep 2021
Posts: 79

PostPosted: Sun Mar 27, 2022 9:46 pm    Post subject: Reply with quote

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:

#!/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
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum