Hello! I wanted to ask: 1. The Arch Linux Wiki has a section 3.2 Using a signed boot loader. Can I skip the previous sections and skip subsection 3.2.1 PreLoader and go straight to section 3.2.2 Shim? 2. If I change the boot loader to grubx64.efi and then if I don't finish section 3.2.2, will everything fail? Nothing will load? And if I leave the boot loader (aka boot.efi, right?) and grubx64.efi, will it crash? 3. Section 3.2.2.1.2 shim with key has: $ openssl req -newkey rsa:4096 -nodes -keyout MOK.key -new -x509 -sha256 -days 3650 -subj "/CN=my Machine Owner Key/" -out MOK.crt $ openssl x509 -outform DER -in MOK.crt -out MOK.cer Should I write "/CN=my Machine Owner Key/" like this? Or do you need to write some sequence of characters? Tell me what to write? P.S. If I make a mistake with any item, then everything will fly for me and it will not be possible to recover?
El lun, 17-07-2023 a las 16:52 +0600, Source Code escribió:
Hello! I wanted to ask: [..] P.S. If I make a mistake with any item, then everything will fly for me and it will not be possible to recover?
Hi! I advise you to take a look at this project: https://github.com/Foxboron/sbctl It makes setting up secure boot trivial. It is infinitely easier than doing the whole process by hand and you could very well have a dual boot. Greetings. -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
Hello. Oscar pointed out to something interesting that I also want to look at, but I'd like to answer your questions so you'll have a bit more understanding on how it works. On 17.07.2023 14:52, Source Code wrote:
Hello! I wanted to ask: 1. The Arch Linux Wiki has a section 3.2 Using a signed boot loader. Can I skip the previous sections and skip subsection 3.2.1 PreLoader and go straight to section 3.2.2 Shim?
You only need one of it. Either PreLoader or shim. Personally I use shim. Both are signed with a key that your mobo can accept, so they both could be launched in Secure Boot mode. Then both of them can load other EFI binaries, GRUB2 in case of shim - as long as it's signed with a key that a signed bootloader trusts itself (for shim you can point out a key to trust with a MokManager.efi tool). So the boot sequence in my case is this: EFI -> shim -> MOK-signed GRUB2 with MOK-signed modules -> MOK-signed Linux kernel
2. If I change the boot loader to grubx64.efi and then if I don't finish section 3.2.2, will everything fail? Nothing will load? And if I leave the boot loader (aka boot.efi, right?) and grubx64.efi, will it crash?
Normally you need to have a shimx64.efi in your NVRAM as a boot option to start the system. You can keep grubx64.efi in your NVRAM as a boot option as well and load it anytime with secure boot disabled. If you switch to grubx64.efi with secure boot - you'll get an error that this binary is untrusted. If you disable it - GRUB2 will load normally. Beware that some EFI implementations can somehow remove it while messing around with boot options via efibootmgr (I saw this a couple of times). So have your USB bootable drive ready, just in case.
3. Section 3.2.2.1.2 shim with key has: $ openssl req -newkey rsa:4096 -nodes -keyout MOK.key -new -x509 -sha256 -days 3650 -subj "/CN=my Machine Owner Key/" -out MOK.crt $ openssl x509 -outform DER -in MOK.crt -out MOK.cer
Should I write "/CN=my Machine Owner Key/" like this? Or do you need to write some sequence of characters? Tell me what to write?
Could be anything really. I have a "/CN=raxp-laptop MOK/" for example. It doesn't matter. You only need a valid X.509 certificate to sign your binaries.
P.S. If I make a mistake with any item, then everything will fly for me and it will not be possible to recover?
Messing with signed bootloader should not harm your device at least, as you don't manage hardware keys directly. Still I'd advise you to keep a bootable USB stick so you can recover. In a worst-case scenario you should be able to revert to GRUB2 to be bootable with secure boot disabled.
On 2023-07-17 09:29 PM, Sergey Filatov wrote:
So the boot sequence in my case is this:
EFI -> shim -> MOK-signed GRUB2 with MOK-signed modules -> MOK-signed Linux kernel
From what I've learned you don't need shim at all, you can boot a signed grub and kernel directly. Apparently you can chainload Windows using shim because it's an MS signed binary but I never got it to work. If you just want Linux to boot have a look at: https://www.reddit.com/r/archlinux/comments/10pq74e/my_easy_method_for_setti... My general method was: - Get UEFI boot working first - Delete all the secure boot keys from your BIOS, ensure setup mode is enabled - Boot and set up and sign everything with sbctl - Enable secure boot in the BIOS, boot - If it doesn't work, enter your BIOS, delete all the keys and go to setup mode again - Try again Cheers. P.S. Always use --disable-shim-lock when installing grub -- Simon Perry (aka Pezz)
You should be careful before deleting all the secure boot keys from your BIOS. Reading the warning at https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secur... : Warning: Replacing the platform keys with your own can end up bricking
hardware on some machines, including laptops, making it impossible to get into the firmware settings to rectify the situation. This is due to the fact that some device (e.g GPU) firmware (OpROMs), that get executed during boot, are signed using Microsoft 3rd Party UEFI CA certificate.
And it would be best to backup those keys before deleting them. There is a command to do so on the same wiki page, a few paragraphs below. Personally, I am just sticking to shim method to stay on the safe side. Le lun. 17 juil. 2023 à 14:24, Simon Perry <arch@sanxion.net> a écrit :
On 2023-07-17 09:29 PM, Sergey Filatov wrote:
So the boot sequence in my case is this:
EFI -> shim -> MOK-signed GRUB2 with MOK-signed modules -> MOK-signed Linux kernel
From what I've learned you don't need shim at all, you can boot a signed grub and kernel directly.
Apparently you can chainload Windows using shim because it's an MS signed binary but I never got it to work.
If you just want Linux to boot have a look at:
https://www.reddit.com/r/archlinux/comments/10pq74e/my_easy_method_for_setti...
My general method was:
- Get UEFI boot working first - Delete all the secure boot keys from your BIOS, ensure setup mode is enabled - Boot and set up and sign everything with sbctl - Enable secure boot in the BIOS, boot - If it doesn't work, enter your BIOS, delete all the keys and go to setup mode again - Try again
Cheers.
P.S. Always use --disable-shim-lock when installing grub
-- Simon Perry (aka Pezz)
On 2023-07-17 11:16 PM, solsTiCe d'Hiver wrote:
You should be careful before deleting all the secure boot keys from your BIOS.
Reading the warning at https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secur...:
Warning: Replacing the platform keys with your own can end up bricking hardware on some machines, including laptops, making it impossible to get into the firmware settings to rectify the situation. This is due to the fact that some device (e.g GPU) firmware (OpROMs), that get executed during boot, are signed using Microsoft 3rd Party UEFI CA certificate.
And it would be best to backup those keys before deleting them. There is a command to do so on the same wiki page, a few paragraphs below.
Personally, I am just sticking to shim method to stay on the safe side.
This might be true, but unlikely that it would stop you getting into the BIOS. Nevertheless, any sane board will let you leave the factory keys installed (or reset to them). Even on my shitty MSI board I wasn't affected by this with no keys, but you're right, it's good to point out. -- Simon Perry (aka Pezz)
On 17 July 2023 13:31:13 UTC, Simon Perry <arch@sanxion.net> wrote:
On 2023-07-17 11:16 PM, solsTiCe d'Hiver wrote:
You should be careful before deleting all the secure boot keys from your BIOS.
Reading the warning at https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secur...:
Warning: Replacing the platform keys with your own can end up bricking hardware on some machines, including laptops, making it impossible to get into the firmware settings to rectify the situation. This is due to the fact that some device (e.g GPU) firmware (OpROMs), that get executed during boot, are signed using Microsoft 3rd Party UEFI CA certificate.
And it would be best to backup those keys before deleting them. There is a command to do so on the same wiki page, a few paragraphs below.
Personally, I am just sticking to shim method to stay on the safe side.
This might be true, but unlikely that it would stop you getting into the BIOS.
This happened to me on an Intel NUC. The GPU firmware wasn't loaded anymore and there was no output on the screen. Even during early boot and the firmware settings. I only managed to restore the backed up keys by following along the restore procedure on a second NUC that still had screen output.
On 2023-07-18 05:51 PM, Maarten de Vries wrote:
This happened to me on an Intel NUC. The GPU firmware wasn't loaded anymore and there was no output on the screen. Even during early boot and the firmware settings.
I only managed to restore the backed up keys by following along the restore procedure on a second NUC that still had screen output.
Ouch. I have a Dell Mini that I'm going to be setting up SB on soon, I'll heed your warning for sure. -- Simon Perry (aka Pezz)
On 2023-07-17 11:16 PM, solsTiCe d'Hiver wrote:
And it would be best to backup those keys before deleting them. There is a command to do so on the same wiki page, a few paragraphs below.
Also, I'm not sure how useful those backup keys are if your system is bricked. -- Simon Perry (aka Pezz)
participants (6)
-
Maarten de Vries
-
Sergey Filatov
-
Simon Perry
-
solsTiCe d'Hiver
-
Source Code
-
Óscar García Amor