| View previous topic :: View next topic |
| Author |
Message |
zen_desu
n00b
Joined: 25 Oct 2024
Posts: 56
|
 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: 20
|
| 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
n00b
Joined: 25 Oct 2024
Posts: 56
|
| 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: 1339
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: 20
|
| 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: 20
|
| 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: 1339
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: 459
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: 20
|
| 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: 20
|
| 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
n00b
Joined: 25 Oct 2024
Posts: 56
|
| 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: 459
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: 1775
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.
_________________
| 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 |
|
|
|
|
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
