How do people deal with Grub's GRUB_SAVEDEFAULT="true" option in secure boot?

Question

How do people deal with Grub's GRUB_SAVEDEFAULT="true" option in secure boot?

Closed this issue 4 years ago · 17 comments

When I have grub remember my last kernel selection. It changes the /boot/grob/grubenv file and grubenv.sig's signature won't be correct, and I can't boot into the kernel is I have secure boot enabled. Is there any way I can solve this? Thanks

Answer 1 · 2020-10-21T07:17:36.000Z

Hi!

Sorry for taking so long.

If your system is stuck in the menu, you can type set check_signatures=no in the grub command line before choosing the menu entry. This is, how ever, temporarily.
If you get stuck earlier just having the grub command line, you can either run the kernel loading commands by hand or you need to chroot your drive from another system.

Once you got into your system I recommend disabling the save-the-last-selection option.
In /etc/default/grub change the line GRUB_DEFAULT=saved to GRUB_DEFAULT=0 to pre-select the first entry. After that run grub-mkconfig -o /boot/grub/grub.cfg and resign it using grub-update-kernel-signature.

I hope it helps!

Answer 2 · 2020-10-21T07:23:41.000Z

Hi Bandie,

Thanks for the reply! That is exactly what I did. However, I was wondering if GRUB_DEFAULT=saved can ever be used in a machine with secure boot enabled? Because it gets annoying to physically switch entries in boot menu all the time(say I want to use windows for these 3 days). Thanks!

Answer 3 · 2020-10-21T07:35:26.000Z

That's a good question. Though I think it wouldn't be possible as it would require ignoring the signature of grubenv, providing a possible target.

Answer 4 · 2020-10-21T07:49:56.000Z

Interesting! I've used debian with secure boot before and I'm not sure how it could have both GRUB_DEFAULT=saved and secureboot at the same time.

Answer 5 · 2020-10-21T07:56:39.000Z

As far as I understand it, secure boot only checks a little part; like saying "this is a GRUB2-installation I made myself and I certify it by $signature" while the payload content itself will not be checked. That's what this GRUB signing stuff is for.

Answer 6 · 2020-10-21T09:26:35.000Z

I see, so does that mean if I let set check_signatures=false but still have secure boot enabled I'd be able to use the GRUB_DEFAULT=saved feature?

Answer 7 · 2020-10-21T11:55:28.000Z

Yes, but this would also mean that there is no signature check anymore.

Answer 8 · 2020-10-21T15:28:22.000Z

Hi Bandie, I just tried to add set check_signatures=no in /etc/grub.d/40_custom but it's giving me error messages when booting:
error: verification requested but nobody cares: (hd0, gpt5)/boot/grub/x86_64-efi/echo.mod ...

Answer 9 · 2020-10-21T17:34:41.000Z

Hey lubyrex,

this should be in the header within the cat << EOF part.
But as I said, it will disable the verification at all..

Answer 10 · 2020-10-22T12:03:31.000Z

Hi Bandie,
I did that then I get "Bootloader has not verified loaded image. System is compromised. halting" error message unless I turn off the secure boot from bios.

Answer 11 · 2020-10-22T12:11:41.000Z

Hey, I just noticed that I was wrong. It has to be set check_signatures=no.

Answer 12 · 2020-10-22T12:25:52.000Z

Hi Bandie,
I ran grub-unsign
added
cat << EOF set check_signatures=enforce EOF
to /etc/grub.d/00_header
Ran grub-mkconfig -o /boot/grub/grub.cfg to make the new configuration valid.
ran grub-sign
But with secure-boot enabled in bios it still reports the same error message:
"Bootloader has not verified loaded image. System is compromised. halting"

Perhaps this is not possible without disabling secure boot?

Answer 13 · 2020-10-22T12:38:40.000Z

Okay, now we get closer. It seems I was partly wrong.. so you actually need to sign and replace the kernel and the grub efi binary.

https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface/Secure_Boot#shim_with_key

Answer 14 · 2020-10-22T13:03:09.000Z

Hi Bandie, I've already signed them with sbsign before:
sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux-surface /boot/vmlinuz-linux-surface
sbsign --key MOK.key --cert MOK.crt --output /efi/EFI/GRUB/grubx64.efi /efi/EFI/GRUB/grubx64.efi

But still got the same error message

Also my /etc/grub.d/40_Custom file used to look like this:
insmod verify
insmod gcry_sha256
insmod gcry_dsa gcry_rsa
set check_signatures=enforce
trust (crypto0)/pubkey
insmod shim_lock

but I've commented all those out and rebuilt my grub config.

Answer 15 · 2020-10-22T13:17:49.000Z

Hmh.. things are getting strange now. Maybe something is up with the MOK not being enrolled anymore for some reason?

Answer 16 · 2020-10-22T13:31:39.000Z

I think I enrolled the key before with MokManager.
It's also strange that in the "Set up shim" section of the Arch wiki, it says to rename my bootloader (which is already grub) to grubx64.efi, and I'm not sure whether that implies it doesn't work with grub. And in the later section that specifically mentions grub "shim with key and GRUB" it uses your grub2-signing-extension to sign all the binaries, which makes it seem like signing everything with the gpg key is a must for secure boot?

Answer 17 · 2020-10-22T14:47:06.000Z

Signing the GPG key is a must for GRUB's signature check, not for secure boot. It's important that the GPG signatures are detached for executable reasons™ (which grub-sign or grub-update-kernel-signature does).
So first signing the things for secure boot using the MOK privkey, then signing it with GPG could be the right order.