Gentoo Forums :: View topic - [SOLVED]Secure GRUB: Verification requested but nobody cares

[SOLVED]Secure GRUB: Verification requested but nobody cares

View unanswered posts
View posts from last 24 hours

Gentoo Forums Forum Index

Other Things Gentoo

View previous topic :: View next topic

Author

Message

regox
Tux's lil' helper

Joined: 12 Sep 2021
Posts: 79

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

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

GDH-gentoo
Veteran
Veteran

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

Posted: Sat Mar 19, 2022 10:43 pm Post subject: Re:

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?

regox
Tux's lil' helper

Joined: 12 Sep 2021
Posts: 79

Posted: Sun Mar 20, 2022 12:10 pm Post subject: Re:

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.

regox
Tux's lil' helper

Joined: 12 Sep 2021
Posts: 79

Posted: Sun Mar 20, 2022 12:19 pm Post subject:

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.

GDH-gentoo
Veteran
Veteran

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

Posted: Sun Mar 20, 2022 3:12 pm Post subject:

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:

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

regox
Tux's lil' helper

Joined: 12 Sep 2021
Posts: 79

Posted: Sun Mar 20, 2022 4:33 pm Post subject:

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.

regox
Tux's lil' helper

Joined: 12 Sep 2021
Posts: 79

Posted: Sun Mar 20, 2022 5:41 pm Post subject:

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.

GDH-gentoo
Veteran
Veteran

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

Posted: Sun Mar 20, 2022 8:56 pm Post subject:

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.

Goverp
Advocate

Joined: 07 Mar 2007
Posts: 2178

Posted: Sun Mar 20, 2022 11:37 pm Post subject:

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

regox
Tux's lil' helper

Joined: 12 Sep 2021
Posts: 79

Posted: Mon Mar 21, 2022 1:39 am Post subject:

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 [...]

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'

regox
Tux's lil' helper

Joined: 12 Sep 2021
Posts: 79

Posted: Mon Mar 21, 2022 1:41 am Post subject:

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.

GDH-gentoo
Veteran
Veteran

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

Posted: Mon Mar 21, 2022 1:40 pm Post subject:

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)".

regox
Tux's lil' helper

Joined: 12 Sep 2021
Posts: 79

Posted: Mon Mar 21, 2022 8:00 pm Post subject:

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?

regox
Tux's lil' helper

Joined: 12 Sep 2021
Posts: 79

Posted: Mon Mar 21, 2022 9:11 pm Post subject:

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?

GDH-gentoo
Veteran
Veteran

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

Posted: Mon Mar 21, 2022 9:45 pm Post subject:

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.

regox
Tux's lil' helper

Joined: 12 Sep 2021
Posts: 79

Posted: Tue Mar 22, 2022 8:41 pm Post subject:

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?

regox
Tux's lil' helper

Joined: 12 Sep 2021
Posts: 79

Posted: Sun Mar 27, 2022 9:46 pm Post subject:

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

1ng0
n00b
n00b

Joined: 21 Jun 2024
Posts: 1

Posted: Fri Jun 21, 2024 5:17 pm Post subject:

regox wrote:

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!

Display posts from previous:

	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

Copyright 2001-2024 Gentoo Foundation, Inc. Designed by Kyle Manna © 2003; Style derived from original subSilver theme. | Hosting by Gossamer Threads Inc. © | Powered by phpBB 2.0.23-gentoo-p11 © 2001, 2002 phpBB Group
Privacy Policy