| View previous topic :: View next topic |
| Author |
Message |
zen_desu
Tux's lil' helper
Joined: 25 Oct 2024
Posts: 105
|
 Posted: Fri Dec 20, 2024 8:21 pm Post subject: |
 |
|
| FlyingBullets wrote: | AH I GOT IT!
| Code: | dmesg | grep -i secure
[ 0.002375] [ T0] Secure boot enabled |
What you have to do is sign the kernel with the UEFI db key AND the GRUB key! More importantly, it needs to be signed with the db key first because it embeds the signature in the kernel, THEN signed with the GRUB key to make the detached signature.
So, in order to use secure boot with GRUB and custom UEFI keys:
1) Make the PK, KEK, and db private keys for the UEFI.
2) Install the 'auth' files generated from the UEFI private keys into the actual UEFI.
3) Make the GRUB key pair with GPG.
4) Extract the public key from the GRUB GPG key pair into some file "grub_public_key".
5) Make the GRUB executable with grub-install with the following options:
* --disable-shim-lock (we are not using shim)
* --pubkey=/path/to/grub_public_key (embeds the public key into the GRUB executable to check the signatures of signed files in /boot)
* --modules="XXX" (XXX is a list of the required modules needed for signature verification; in this case, it's "pgp", "gcry_sha256", and "gcry_rsa")
6) Sign all EFI files that will be used in the boot chain with the UEFI db key with sbsign; this includes the GRUB executable and any kernels.
7) Sign all
* kernels
* inramfses
* microcode
* GRUB modules, configs, environment blocks, etc
with the GRUB GPG key to create a detached signature for all of them.
I will add detailed instructions to the "Secure Boot" wiki page soon.
Thanks everyone who helped solve this issue, especially you GDH-gentoo! |
Thanks for looking into this, if you make a page do you think you can make a subpage for this GRUB stuff?
It may be worth considering a UKI so fewer files need to be signed.
_________________
µgRD dev
Wiki writer |
|
| Back to top |
|
 |
FlyingBullets
n00b
Joined: 19 Mar 2024
Posts: 21
|
| Posted: Fri Dec 20, 2024 9:25 pm Post subject: |
|
|
| zen_desu wrote: | | Thanks for looking into this, if you make a page do you think you can make a subpage for this GRUB stuff? |
I first want to make a script that automates the entire process so I can verify that everything is correct. I'm not sure how this information should be formatted in the "Secure Boot" wiki page (Should it be in the "Signing" section or should it get its own section?), I have to take another look. Once it's done, I can make a reference to it in the "GRUB" wiki page.
| zen_desu wrote: | | It may be worth considering a UKI so fewer files need to be signed. |
True, and I could make an additional note about it, but it also requires more dependencies due to the additional "uki" USE flag. I have sys-kernel/installkernel installed with USE="dracut grub" -- it does everything I need it to: compile and update the kernel, initramfs, and GRUB config. All I have to do is make a ~5 line script that signs the files in /boot. |
|
| Back to top |
|
|
zen_desu
Tux's lil' helper
Joined: 25 Oct 2024
Posts: 105
|
| Posted: Fri Dec 20, 2024 9:33 pm Post subject: |
|
|
| FlyingBullets wrote: | | zen_desu wrote: | | Thanks for looking into this, if you make a page do you think you can make a subpage for this GRUB stuff? |
I first want to make a script that automates the entire process so I can verify that everything is correct. I'm not sure how this information should be formatted in the "Secure Boot" wiki page (Should it be in the "Signing" section or should it get its own section?), I have to take another look. Once it's done, I can make a reference to it in the "GRUB" wiki page.
|
I mean you could make a subpage like "Secure Boot/GRUB", because most of that process is unique to GRUB afaik. That and I agree it would be very hard to fit this info on the "main" page while having it still be clear for efi stub setups.
It could possibly even be "GRUB/Secure boot", as it seems most of this stuff is just extra considerations for GRUB, and doesn't apply for other setups.
| FlyingBullets wrote: | | zen_desu wrote: | | It may be worth considering a UKI so fewer files need to be signed. |
True, and I could make an additional note about it, but it also requires more dependencies due to the additional "uki" USE flag. I have sys-kernel/installkernel installed with USE="dracut grub" -- it does everything I need it to: compile and update the kernel, initramfs, and GRUB config. All I have to do is make a ~5 line script that signs the files in /boot. |
I wonder if it would be possible to make a USE flag on GRUB which installs a hook that does this for you, that may not be the right place.
UKI does add more deps, but it can greatly simplify the signing process.
_________________
µgRD dev
Wiki writer
Last edited by zen_desu on Fri Dec 20, 2024 10:32 pm; edited 1 time in total |
|
| Back to top |
|
|
pingtoo
Veteran
Joined: 10 Sep 2021
Posts: 1410
Location: Richmond Hill, Canada
|
| Posted: Fri Dec 20, 2024 9:46 pm Post subject: |
|
|
May I suggest while you prepare making document for this secure boot, you can differentiate "uki" and "efistub kernel"
I found many confusing procedure/descriptions talk about secure boot with clearly mixing two so it lead to very difficult to understand the procedure and much frustration. |
|
| Back to top |
|
|
FlyingBullets
n00b
Joined: 19 Mar 2024
Posts: 21
|
| Posted: Fri Dec 20, 2024 9:57 pm Post subject: |
|
|
| zen_desu wrote: | | I mean you could make a subpage like "Secure Boot/GRUB" |
I think this is the way to go, otherwise the "Secure Boot" page would be a kilometer long.
| zen_desu wrote: | | I wonder if it would be possible to make a USE flag on GRUB which installs a hook that does this for you, that may not be the right place. |
sys-boot/grub has a "secureboot" USE flag that states it signs the EFI executable, but in my testing, it doesn't even do that! This might be something worth reporting unless I'm using it wrong. I don't know how though, the description of the USE flag implies that grub-install will automatically sign the EFI... but it doesn't.
In /etc/portage/make.conf, there are the variables:
| Code: | SECUREBOOT_SIGN_KEY="..."
SECUREBOOT_SIGN_CERT="..." |
that get used to sign things with the UEFI db key.
The developers could update the "secureboot" USE flag so that it:
1) fixes the signing of the GRUB EFI executable (/efi/EFI/BOOT/BOOTX64.EFI in my case).
2) has GRUB make use of another variable in make.conf, say,
| Code: | | GRUB_SIGN_KEY="..." |
to sign all the needed files in /boot. |
|
| Back to top |
|
|
FlyingBullets
n00b
Joined: 19 Mar 2024
Posts: 21
|
| Posted: Fri Dec 20, 2024 10:12 pm Post subject: |
|
|
| pingtoo wrote: | | May I suggest while you prepare making document for this secure boot, you can differentiate "uki" and "efistub kernel" |
Yes, I will make a subpage "Secure Boot/GRUB" that will also explain "UKI" and "efistub" kernels; they should work with GRUB because GRUB is simply loading a kernel that you select. So if you're using a UKI or an efistub right now, you will be able to utilize GRUB to be able to select a specific one at boot time. |
|
| Back to top |
|
|
pingtoo
Veteran
Joined: 10 Sep 2021
Posts: 1410
Location: Richmond Hill, Canada
|
| Posted: Fri Dec 20, 2024 10:20 pm Post subject: |
|
|
| FlyingBullets wrote: | | pingtoo wrote: | | May I suggest while you prepare making document for this secure boot, you can differentiate "uki" and "efistub kernel" |
Yes, I will make a subpage "Secure Boot/GRUB" that will also explain "UKI" and "efistub" kernels; they should work with GRUB because GRUB is simply loading a kernel that you select. So if you're using a UKI or an efistub right now, you will be able to utilize GRUB to be able to select a specific one at boot time. |
For your information. Actually GRUB by default cannot work UKI/efistub. Because they have PE header.
For GRUB to work you will need to use chainloader in GRUB. |
|
| Back to top |
|
|
Nowa
Developer
Joined: 25 Jun 2014
Posts: 470
Location: Nijmegen
|
| Posted: Fri Dec 20, 2024 10:29 pm Post subject: |
|
|
| Quote: |
The developers could update the "secureboot" USE flag so that it:
1) fixes the signing of the GRUB EFI executable (/efi/EFI/BOOT/BOOTX64.EFI in my case).
2) has GRUB make use of another variable in make.conf, say,
| Code: | | GRUB_SIGN_KEY="..." |
to sign all the needed files in /boot. |
The secureboot flag does do this, it is just that grub-install does not use this signed EFI file that portage builds. As I said in my previous reply you have to copy this file and *not* use grub-install. If you do use grub-install then you are on your own to sign it and ensure the required modules are included, it is highly impractical to modify/patch the behaviour of grub-install downstream as you suggest. Because contrary to what the name suggests, grub-install does not just install grub, it builds the grub EFI executable, and hence this is all entirely outside of the control of portage.
To sign your kernels in /boot you use the same SECUREBOOT_ variables and the secureboot flag but for the kernel packages, all this gpg signing is not required, the kernels will pass verification if they are signed with the same key as the bootloader. GRUBs gpg capabilities are something entirely independent from secureboot. Gpg signatures is not something we can practically support automating via portage, and it is not necessary since openssl signing is already in place via the securboot use flag.
If you do not want to use portages signing facilities for whatever reason you can alternatively use the sbctl package which provides installkernel hooks to sign the installed kernels in the installation stage (instead of in the building phase as portage would do). Again this would be using openssl and not gpg in the background.
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400
Last edited by Nowa on Fri Dec 20, 2024 10:31 pm; edited 1 time in total |
|
| Back to top |
|
|
FlyingBullets
n00b
Joined: 19 Mar 2024
Posts: 21
|
| Posted: Fri Dec 20, 2024 10:30 pm Post subject: |
|
|
| pingtoo wrote: | | For GRUB to work you will need to use chainloader in GRUB. |
Ah yes, that's right. |
|
| Back to top |
|
|
FlyingBullets
n00b
Joined: 19 Mar 2024
Posts: 21
|
| Posted: Fri Dec 20, 2024 11:07 pm Post subject: |
|
|
| Nowa wrote: | The secureboot flag does do this, it is just that grub-install does not use this signed EFI file that portage builds. As I said in my previous reply you have to copy this file and *not* use grub-install. If you do use grub-install then you are on your own to sign it and ensure the required modules are included, it is highly impractical to modify/patch the behaviour of grub-install downstream as you suggest. Because contrary to what the name suggests, grub-install does not just install grub, it builds the grub EFI executable, and hence this is all entirely outside of the control of portage.
To sign your kernels in /boot you use the same SECUREBOOT_ variables and the secureboot flag but for the kernel packages, all this gpg signing is not required, the kernels will pass verification if they are signed with the same key as the bootloader. GRUBs gpg capabilities are something entirely independent from secureboot. Gpg signatures is not something we can practically support automating via portage, and it is not necessary since openssl signing is already in place via the securboot use flag.
If you do not want to use portages signing facilities for whatever reason you can alternatively use the sbctl package which provides installkernel hooks to sign the installed kernels in the installation stage (instead of in the building phase as portage would do). Again this would be using openssl and not gpg in the background. |
I think the reason why those other options didn't work for me is that I wanted to use my own keys, so any solution involving shim wouldn't work (I have no idea). I tried the signed EFI file /usr/lib/grub/grub*.signed, but it didn't work. When I tried to use sbctl, it wasn't able to enroll keys in the UEFI even after I put it in "Setup" mode.
Maybe they didn't work because I have an external initramfs and microcode. |
|
| Back to top |
|
|
zen_desu
Tux's lil' helper
Joined: 25 Oct 2024
Posts: 105
|
| Posted: Sat Dec 21, 2024 3:20 am Post subject: |
|
|
| FlyingBullets wrote: |
Maybe they didn't work because I have an external initramfs and microcode. |
The initramfs and microcode are not verified by secure boot. This may be a security issue which is why packing them into a UKI can help.
The initramfs/microcode are just CPIO archives which are used as filesystems for the kernel in the early boot process, "secure boot" is not checking the validity of these files if they are external.
_________________
µgRD dev
Wiki writer |
|
| Back to top |
|
|
Nowa
Developer
Joined: 25 Jun 2014
Posts: 470
Location: Nijmegen
|
| Posted: Sat Dec 21, 2024 8:05 am Post subject: |
|
|
| FlyingBullets wrote: |
I think the reason why those other options didn't work for me is that I wanted to use my own keys, so any solution involving shim wouldn't work (I have no idea). I tried the signed EFI file /usr/lib/grub/grub*.signed, but it didn't work. When I tried to use sbctl, it wasn't able to enroll keys in the UEFI even after I put it in "Setup" mode.
Maybe they didn't work because I have an external initramfs and microcode. |
This does not require shim, nor does it matter if the initramfs is external or in an UKI. What does matter is the contents and location of the grub.cfg, this is different for the grub-mkstandalone approach that the ebuild uses, this is documented in the handbook.
If with a proper config in the right location it still does not work, then there could be some bug.
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400 |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1791
Location: South America
|
| Posted: Sat Dec 21, 2024 11:07 am Post subject: |
|
|
| Nowa wrote: | | This does not require shim, [...] |
I think it does, did you see the part of this thread where GRUB loading the kernel failed with "error: shim_lock protocol not found"? If it's not about this, then I don't know what it is about.
And if I'm right, the OP had only two alternatives: installing the Shim (likely signed with one the the OP's keys, since the Microsoft key used for signing the Shim that we borrow from Fedora would have its corresponding public one wiped from the secure boot db), which the OP didn't want, or going the OpenPGP signatures route, which was the taken alternative.
| Nowa wrote: | | Gpg signatures is not something we can practically support automating via portage, [...] |
You are probably right, though, so all work would have to be done by the user. I do appreciate that there is now an automation for at least some secure boot scenarios.
_________________
| NeddySeagoon wrote: | I'm not a witch, I'm a retired electronics engineer  |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
Nowa
Developer
Joined: 25 Jun 2014
Posts: 470
Location: Nijmegen
|
| Posted: Sat Dec 21, 2024 11:56 am Post subject: |
|
|
| GDH-gentoo wrote: | | Nowa wrote: | | This does not require shim, [...] |
I think it does, did you see the part of this thread where GRUB loading the kernel failed with "error: shim_lock protocol not found"? If it's not about this, then I don't know what it is about. |
The shim lock is optional and can be disabled via UEFI variable: https://www.gnu.org/software/grub/manual/grub/html_node/UEFI-secure-boot-and-shim.html
| Quote: | | If it is desired to use UEFI secure boot without shim, one can disable shim_lock by disabling shim verification with MokSbState UEFI variable or by building grub image with ‘--disable-shim-lock’ option. |
Or, alternatively, you can bypass the shim lock by using the chainload command to load the kernel instead (as a side note, this behaviour is why UKI's are not support in GRUB when secureboot is enabled via shim: https://bugs.gentoo.org/942201)
| Quote: | | The GRUB, except the chainloader command, works with the UEFI secure boot and the shim. |
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400 |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1791
Location: South America
|
| Posted: Sat Dec 21, 2024 1:34 pm Post subject: |
|
|
| Nowa wrote: | | The shim lock is optional and can be disabled via UEFI variable: [...] |
If you mean MokSbState, it's not a random UEFI variable: it's also managed by the Shim.
1) You have to go through the mokutil --> set password --> boot --> MokManager --> verify password dance to set that (which I hope cannot be easily subverted), so it also needs the Shim.
2) GRUB's manual does not explain it, but if I understand correctly, this disables validation completely, which is likely not what secure boot users want. This is not surprising though, AFAICT what triggers the code path for setting MokSBState to 1 in MokManager is requesting mokutil --disable-validation, so GRUB would just be extending the request to its own validations.
On the other hand, using the --disable-shim-lock option is what the OP did, and that forces the use of OpenPGP signatures.
| Nowa wrote: | | Or, alternatively, you can bypass the shim lock by using the chainload command to load the kernel instead (as a side note, this behaviour is why UKI's are not support in GRUB when secureboot is enabled via shim: https://bugs.gentoo.org/942201) |
I'm not sure if the claim that the manual makes about chainloader not doing signature verification with the shim_lock protocol is still accurate, though. And I note that grub-mkconfig does not generate chainloader commands for Linux kernels. Users that manage grub.cfg directly can do that, of course, grub-mkconfig is not mandatory for managing GRUB's configuration.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
Nowa
Developer
Joined: 25 Jun 2014
Posts: 470
Location: Nijmegen
|
| Posted: Sat Dec 21, 2024 2:08 pm Post subject: |
|
|
| GDH-gentoo wrote: |
I'm not sure if the claim that the manual makes about chainloader not doing signature verification with the shim_lock protocol is still accurate, though. |
It is for any version of grub we have in ::gentoo, that is one of the problems being tracked here: https://bugs.gentoo.org/942201
Note that Fedora/Ubuntu and derivatives carry patches for this, though AFAIK they have not been upstreamed.
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400 |
|
| Back to top |
|
|
FlyingBullets
n00b
Joined: 19 Mar 2024
Posts: 21
|
| Posted: Sat Dec 21, 2024 6:47 pm Post subject: |
|
|
| zen_desu wrote: | The initramfs and microcode are not verified by secure boot. This may be a security issue which is why packing them into a UKI can help.
The initramfs/microcode are just CPIO archives which are used as filesystems for the kernel in the early boot process, "secure boot" is not checking the validity of these files if they are external. |
This is true: secure boot does not check these files (it only checks EFI files), but GRUB does with the GPG signatures. I just checked by renaming the initramfs-x.y.z-gentoo.img.sig to something else: GRUB refused to boot and gave the error message:
| Code: | Booting `Gentoo GNU/Linux'
Loading Linux x.y.z-gentoo ...
Loading initial ramdisk ...
error: file `/initramfs-x.y.z-gentoo.img.sig' not found.
Press any key to continue... |
A similar error appeared when the microcode signature file was not available as I stated in a previous post:
| FlyingBullets wrote: | | ... After I made this change, GRUB complained that the microcode files were not signed (/boot/*-uc.img), so I signed those as well. FINALLY the machine booted like normal... |
##########################
| Nowa wrote: | This does not require shim, nor does it matter if the initramfs is external or in an UKI. What does matter is the contents and location of the grub.cfg, this is different for the grub-mkstandalone approach that the ebuild uses, this is documented in the handbook.
If with a proper config in the right location it still does not work, then there could be some bug. |
I ran the following commands with the SECUREBOOT_SIGN_* variables set in /etc/portage/make.conf:
| Code: | USE="secureboot" emerge -uND @world
cd /usr/src/linux
export GRUB_CFG=/efi/EFI/BOOT/grub.cfg
make && make modules_install && make install
cp /usr/lib/grub/grub-x86_64.efi.signed /efi/EFI/BOOT/BOOTX64.EFI |
I rebooted, the GRUB menu showed up, but after the first entry was selected, I got the following error:
| Code: | Booting `Gentoo GNU/Linux'
Loading Linux x.y.z-gentoo ...
error: shim_lock protocol not found.
Loading initial ramdisk ...
error: you need to load the kernel first.
Failed to boot both default and fallback entries.
Press any key to continue... |
|
|
| Back to top |
|
|
|
|
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
|
|
Kernel & Hardware
