Awesome tutorial. I took the approach of combining the original esl backups with my own and am finally able to sign and boot ipxe.efi 😀 The only part I couldn't figure out is, must I enroll my own PK, or is it possible to re-enroll the original PK? I suppose if I retain Lenovo, Dell, and/or Microsoft's KEK that I should have no problems with UEFI based firmware updates.
That's great to hear. You need to have your own PK. Do not re-enroll the original PK. You can keep the original KEKs, db, and dbx without issue. Make sure to sign KEKs with your own PK key.
I don't think there are any other ways to remove keys from firmware besides using firmware setup, unless the keys enrolled in firmware are your own. In that case, you can remove the keys from firmware from the command line something like this: # chattr -i /sys/firmware/efi/efivars/{PK,KEK,db,dbx}* # efi-updatevar -d 0 -k /keys/PK.key PK Since you do not own the Platform Key (PK) at the beginning, you must use the UEFI firmware setup to remove the keys. That is why it is critical to password protect your firmware setup so that no one can reset secure boot keys.
Hi sys excellent quality of vids. I am a noob so might wanna watch it again and again. However I have one question i wanna do this experiment on virtualbox-ubunutu. So it would not mess up my real hardware uefi settings right? Also it'd not mess my vbox uefi settings for other machines like vbox-debian?
It will have no effect on either your real hardware or other virtual machines. So don't worry, just go for it. Even for the virtual machine you're experimenting with, you can reset the UEFI firmware to restore the original.
@@SysGuides thanks man appreciate it Last question I'm having two scenarios in vbox-windows In vbox-windows settings -> system 1. When I "Reset keys to default" and uncheck "Enable secure boot" I am booting in windows hassle free 2. However when I "Reset keys to default" and leave "Enable secure boot" checked then Vbox efi splash screen doesn't shows up and it never boots up ever(except reverting snapshot) Thanks for entertaining me. 😀
I want to install Nvidia with Secure Boot enabled on Fedora 40, should I generate key using (kmodgenca) before or after installing Nvidia drivers? 1. sudo install akmod-nvidia xorg-x11-drv-nvidia-cuda 2. sudo kmodgenca -a 3. sudo mokutil --import /etc/pki/akmods/certs/public_key.der 4. systemctl reboot Is the order of commands right??
What do you mean when you say "OEM"? Is that synonymous to mainboard manufacturer? And another question: According to 31:52, the DB key can only be imported into the DB signature/key NVRAM store if KEK and PK are not yet loaded, even though DB is signed by KEK. If this is true, how does Microsoft add KEK-signed DB keys into NVRAM during Windows updates without user interaction?
@@SysGuides Thanks a lot for the answer (which I saw too late)! I added another question into the same comment. I'd appreciate if you could also share some insight on that. Thanks!
I'm not sure how Windows sets up secure boot keys. Keys can be enrolled into secure boot using several tools that are available based on the operating system. Each tool has its own procedures. A couple of things to clarify. Secure Boot operates in two modes. The first is 'Setup mode,' which allows you to add and delete keys. Secure Boot does not function in this mode. When you add a Platform Key (PK), it will switch to 'User mode'. In User mode, Secure Boot is enabled, and it begins checking signatures and hashes. At the time stamp you specified, I was in Setup mode. So, in setup mode, you add keys in the following order: dbx, db, KEK, and PK. So, how does Windows add its db and KEK? No, Microsoft doesn't add keys. Microsoft publishes their db and KEK public keys on their website. It is up to the OEM or motherboard manufacturer to include them (if they want Windows to run) while configuring secure boot. Once they add Microsoft Keys (dbx, db, and KEK) and finish by adding their own PK, they are ready to sell. If you look at my article, you'll see that I did the same thing. sysguides.com/fedora-uefi-secure-boot-with-custom-keys#19-9-add-microsoft-keys-to-uefi-secure-boot When Windows updates, only the dbx is updated; I'm not sure if the db is updated. Anyway, it may be possible in Windows, but as far as I know, in Fedora, if you want to update dbx (or db), you must temporarily remove PK. sysguides.com/fedora-uefi-secure-boot-with-custom-keys#22-93-microsoft-forbidden-signature-database-dbx
@@SysGuides Thanks for your reply! I understand that KEK cannot be updated at Microsoft's will, as KEK needs to be signed by PK. As for the DB keys, Microsoft will update them (or has started to update them) starting February 2024. I cannot link to the MS article as the "smart" RUclips algorithm will delete my comment if I do. MS intent to also update the KEK but they're not giving much detail (must happen in cooperation with the OEMs, so some older hardware will likely miss out). I guess the point I'm trying to make is that updating KEK and DB must be possible without user interaction and without removing PK, as long as KEK is signed by PK and DB is signed by KEK (i.e. there is nothing in the computer's firmware preventing this). The MS article only mentions something about needing to reboot twice. If you google "Updating Microsoft Secure Boot keys 2024" you will find the article on the Windows IT Pro Blog.
@@Alestrix76 I just read the article. You are correct; it would be nice to update KEK and db without requiring user interaction, as well as without removing PK. Maybe it's possible in Windows. As for the newest Microsoft certificates for 2023, I have already done so in my article. So it's already taken care of. sysguides.com/fedora-uefi-secure-boot-with-custom-keys#19-9-add-microsoft-keys-to-uefi-secure-boot
Thank you! Extremely helpful Just one question, do you know why i might be receiving the following error: "Failed to update db: Invalid argument" After the command: "efi-updatevar -f db.auth db"
Perhaps the file attribute is set to immutable. Check the file's attributes. lsattr /sys/firmware/efi/efivars/db-* There could be more reasons. Updating UEFI variables in firmware is very tricky. You must update in a specific order, and when updating other variables, the PK key should not exist.
@@SysGuides Thank you for your response. In my case the problem was that I thought i have deleted the PK, but i didn't. If i delete the original PK in the UEFI menu, and reboot my system, it automatically returns and is not deleted anymore. For it to work I need to delete the PK and not reboot the system. Delete and go straight into linux to make the commands to enroll the new key.
Hi sysguides i was able sign the kernel and it boots perfectly however after updating kernel the new kernel says bad shim signature .... you need to load kernel first However the previous kernel boots perfectly from grub Is there a way to verify the new kernel or enroll it to db?
The kernels will be signed by Fedora. Even if you don't sign them, there should be no problem. Check the shim to see if it has your signature: pesign -S -i /boot/efi/EFI/fedora/shimx64.efi For more information, see my text article: sysguides.com/fedora-uefi-secure-boot-with-custom-keys
When i try to enroll PK.auth "efi-updatevar -f /root/keys/auth/PK.auth PK get the error "Failed to update PK: Invalid Argument, how can i fix this problem? I applied everything same as steps.
When i try to enroll db.auth using "sudo efi-updatevar -f /keys/auth/db.auth db" i get the error Failed to update db: operation not permitted. For the life of me i cannot seem to find a solution.
![BAK Jay - Find Out (For Your Love) [Official Music Video]](http://i.ytimg.com/vi/10FJO_XBCvY/mqdefault.jpg)
Been watching your videos for a while, always extremely helpful and informative. Thank you
Glad you like them!
Awesome tutorial. I took the approach of combining the original esl backups with my own and am finally able to sign and boot ipxe.efi 😀 The only part I couldn't figure out is, must I enroll my own PK, or is it possible to re-enroll the original PK? I suppose if I retain Lenovo, Dell, and/or Microsoft's KEK that I should have no problems with UEFI based firmware updates.
That's great to hear. You need to have your own PK. Do not re-enroll the original PK. You can keep the original KEKs, db, and dbx without issue. Make sure to sign KEKs with your own PK key.
Red-Hat folks manufactor motherboards as well? ....thats Instresting!
*_Owns_* the Platform Key on the virtual motherboard with TianoCore virtual UEFI firmware on virtual machines installed on the KVM hypervisor.
Great explanation! What are the other ways to remove the secure boot keys without using the firmware configuration that you mentioned?
I don't think there are any other ways to remove keys from firmware besides using firmware setup, unless the keys enrolled in firmware are your own.
In that case, you can remove the keys from firmware from the command line something like this:
# chattr -i /sys/firmware/efi/efivars/{PK,KEK,db,dbx}*
# efi-updatevar -d 0 -k /keys/PK.key PK
Since you do not own the Platform Key (PK) at the beginning, you must use the UEFI firmware setup to remove the keys. That is why it is critical to password protect your firmware setup so that no one can reset secure boot keys.
@@SysGuides Got it! Thank you
Hi Sysguide, mine says no filesystem mounted?
Hi sys excellent quality of vids.
I am a noob so might wanna watch it again and again.
However I have one question i wanna do this experiment on virtualbox-ubunutu.
So it would not mess up my real hardware uefi settings right? Also it'd not mess my vbox uefi settings for other machines like vbox-debian?
It will have no effect on either your real hardware or other virtual machines. So don't worry, just go for it. Even for the virtual machine you're experimenting with, you can reset the UEFI firmware to restore the original.
@@SysGuides thanks man appreciate it
Last question
I'm having two scenarios in vbox-windows
In vbox-windows settings -> system
1. When I "Reset keys to default" and uncheck "Enable secure boot" I am booting in windows hassle free
2. However when I "Reset keys to default" and leave "Enable secure boot" checked then Vbox efi splash screen doesn't shows up and it never boots up ever(except reverting snapshot)
Thanks for entertaining me. 😀
@@AnxulJyoti I haven't used Virtualbox that much. However, clearing and resetting Virtualbox UEFI variables is ridiculous. I recommend using KVM.
I want to install Nvidia with Secure Boot enabled on Fedora 40, should I generate key using (kmodgenca) before or after installing Nvidia drivers?
1. sudo install akmod-nvidia xorg-x11-drv-nvidia-cuda
2. sudo kmodgenca -a
3. sudo mokutil --import /etc/pki/akmods/certs/public_key.der
4. systemctl reboot
Is the order of commands right??
What do you mean when you say "OEM"? Is that synonymous to mainboard manufacturer?
And another question: According to 31:52, the DB key can only be imported into the DB signature/key NVRAM store if KEK and PK are not yet loaded, even though DB is signed by KEK. If this is true, how does Microsoft add KEK-signed DB keys into NVRAM during Windows updates without user interaction?
Yes. When you build your own PC, the PK will usually come from a motherboard manufacturer.
@@SysGuides Thanks a lot for the answer (which I saw too late)! I added another question into the same comment. I'd appreciate if you could also share some insight on that. Thanks!
I'm not sure how Windows sets up secure boot keys. Keys can be enrolled into secure boot using several tools that are available based on the operating system. Each tool has its own procedures.
A couple of things to clarify. Secure Boot operates in two modes. The first is 'Setup mode,' which allows you to add and delete keys. Secure Boot does not function in this mode. When you add a Platform Key (PK), it will switch to 'User mode'. In User mode, Secure Boot is enabled, and it begins checking signatures and hashes.
At the time stamp you specified, I was in Setup mode. So, in setup mode, you add keys in the following order: dbx, db, KEK, and PK.
So, how does Windows add its db and KEK? No, Microsoft doesn't add keys.
Microsoft publishes their db and KEK public keys on their website. It is up to the OEM or motherboard manufacturer to include them (if they want Windows to run) while configuring secure boot. Once they add Microsoft Keys (dbx, db, and KEK) and finish by adding their own PK, they are ready to sell.
If you look at my article, you'll see that I did the same thing. sysguides.com/fedora-uefi-secure-boot-with-custom-keys#19-9-add-microsoft-keys-to-uefi-secure-boot
When Windows updates, only the dbx is updated; I'm not sure if the db is updated.
Anyway, it may be possible in Windows, but as far as I know, in Fedora, if you want to update dbx (or db), you must temporarily remove PK.
sysguides.com/fedora-uefi-secure-boot-with-custom-keys#22-93-microsoft-forbidden-signature-database-dbx
@@SysGuides Thanks for your reply! I understand that KEK cannot be updated at Microsoft's will, as KEK needs to be signed by PK. As for the DB keys, Microsoft will update them (or has started to update them) starting February 2024. I cannot link to the MS article as the "smart" RUclips algorithm will delete my comment if I do. MS intent to also update the KEK but they're not giving much detail (must happen in cooperation with the OEMs, so some older hardware will likely miss out).
I guess the point I'm trying to make is that updating KEK and DB must be possible without user interaction and without removing PK, as long as KEK is signed by PK and DB is signed by KEK (i.e. there is nothing in the computer's firmware preventing this). The MS article only mentions something about needing to reboot twice. If you google "Updating Microsoft Secure Boot keys 2024" you will find the article on the Windows IT Pro Blog.
@@Alestrix76 I just read the article. You are correct; it would be nice to update KEK and db without requiring user interaction, as well as without removing PK. Maybe it's possible in Windows.
As for the newest Microsoft certificates for 2023, I have already done so in my article. So it's already taken care of.
sysguides.com/fedora-uefi-secure-boot-with-custom-keys#19-9-add-microsoft-keys-to-uefi-secure-boot
Thank you! Extremely helpful
Just one question, do you know why i might be receiving the following error:
"Failed to update db: Invalid argument"
After the command:
"efi-updatevar -f db.auth db"
Perhaps the file attribute is set to immutable. Check the file's attributes.
lsattr /sys/firmware/efi/efivars/db-*
There could be more reasons. Updating UEFI variables in firmware is very tricky. You must update in a specific order, and when updating other variables, the PK key should not exist.
@@SysGuides Thank you for your response.
In my case the problem was that I thought i have deleted the PK, but i didn't. If i delete the original PK in the UEFI menu, and reboot my system, it automatically returns and is not deleted anymore.
For it to work I need to delete the PK and not reboot the system. Delete and go straight into linux to make the commands to enroll the new key.
@@marcoabensur4196 I'm glad everything worked out for you in the end.
Hi sysguides i was able sign the kernel and it boots perfectly however after updating kernel the new kernel says bad shim signature .... you need to load kernel first
However the previous kernel boots perfectly from grub
Is there a way to verify the new kernel or enroll it to db?
The kernels will be signed by Fedora. Even if you don't sign them, there should be no problem.
Check the shim to see if it has your signature:
pesign -S -i /boot/efi/EFI/fedora/shimx64.efi
For more information, see my text article:
sysguides.com/fedora-uefi-secure-boot-with-custom-keys
When i try to enroll PK.auth "efi-updatevar -f /root/keys/auth/PK.auth PK get the error "Failed to update PK: Invalid Argument, how can i fix this problem? I applied everything same as steps.
how does this compare to shim? isn't shim supposed to be an easier way of doing this?
Yes. But this video focuses on taking full control of the secure boot key chain.
Danke!
You are most welcome and thanks for your support 😊
When i try to enroll db.auth using "sudo efi-updatevar -f /keys/auth/db.auth db" i get the error Failed to update db: operation not permitted. For the life of me i cannot seem to find a solution.
Can you solve problem?