Secure boot forbids loading modes from...error still after signing my kernel and grubx64.efi with sbsign!

For issues with MX that has been modified from the initial install. Example: adding packages that then cause issues.
Post Reply
Message
Author
User avatar
jmon
Posts: 1
Joined: Sun Apr 21, 2019 7:40 am

Secure boot forbids loading modes from...error still after signing my kernel and grubx64.efi with sbsign!

#1 Post by jmon »

😂 So for last month or two I've been figuring out how to DIY make MX Linux work with Secure Boot, since distro doesn't support it natively; I've taken more heroic measures than usual because MX Linux might be the next Ubuntu, since that distro is on a significant decline in user-friendliness and quality...Open Suse Leap is okay...but more work to get multimedia codecs and Nvidia driver soft-repositories working. So after cross-reading many LONG tedious technical manuals including this snippet: https://forums.gentoo.org/viewtopic-...0-start-0.html 🤔. To further complicate things...if you read I used the read-only mount which doesn't work when doing any writes to part of 'non-violatile ram' of UEFI that has UEFI variables...and was the shallower learning curve - I spent a FULL two weeks on figuring out how to change the keystore parts of UEFI variables, which meant having to both preserve my 'factory default keys' -INCLUDING CRITICAL HARDWARE-RECOGNITION SIGNINGS BY ASUS, US OH and EVEN Microsoft keys- AND also 'appending' my own keys. To avoid bricking my UEFI firmware😱 possibly irreversibably I checked NOT once, NOT twice, but THREE times to assure that I saved a precise mult-file state of Platform Key store, Key-Exchange-Key store, database store and forbidden-database store! I vigilantly spaced out this triple-checking to make sure I actually clicked 'Save Secure Boot Keys' option like I had thought...since there would otherwise be HELL. Wait...it gets better I had to find an "aftermarket" version of efitools package, since the original distro package database didn't include this and only included efivar package - a day or two just to find that!😤 Finally I followed guide: https://wiki.gentoo.org/wiki/Sakaki%...ng_Secure_Boot. https://wiki.gentoo.org/wiki/Sakaki%..._efi-updatevar 😂. Then I had to spend a day googling about how to use these new enrolled keys and further figuring out more tedious command-line syntax of sbsign program! Also, I had to delete original PK key, to allow any key storage programming...disabling Secure Boot on ASUS-brand motherboards counterintiuvely doesn't unload keys!!!!!!😈 So, the moment came -drums rolling- to test out whether I passed to Secure Boot's satisfaction...with a dissappointing Secure Boot telling me that it detected an invalid signature...or SAW no signature -UGGGGGGH!😋-...a week or two went by and I read god-knows-how-many forum postings...guides...just to find that shim wasn't already signed by my enrolled Microsoft UEFI Certificate Authority key...even though it was originally made by Microsoft itself to allow linux users to have same Secure Boot protections from pre-boot environment malware while allowing a different-sig signed bootloader by distro -a firmware-level malware wouldn't care whether I run Linux, Windows or BOTH- https://www.standard.net/news/busine...3ef6edf73.html... so I got one package that explicitly says its signed and debian-signed distro-shipped Grub bootloader. A step forward, but then I got a 🤔cryptic error of Secure Boot forbids loading module from"...so back to googling...(this is starting to get tiresome by this point)...I try "grub --install --uefi-secure-boot" but same result came boot time...so then I tried looking up how to sign all 260 -was-it?- grub modules after I tried for a few hours😫 there to figure out if sbsign or a better signing program would allow me to mass-sign-in-a-batch! But no avail...so I was, crazy as it sounds, going to do a mind-numbing and physically exhausting task of repetitvely signing EVERY module-one-by-one!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! If only that would of worked cause now I have hit a brick wall for the last few hours...IT STILL BITCHES ABOUT IT SOMEHOW WANTS SIGNING MODULES!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!😪 So, I'm reaching out to the MX Linux forum...😂

User avatar
sunrat
Posts: 636
Joined: Mon Mar 28, 2016 9:54 pm

Re: Secure boot forbids loading modes from...error still after signing my kernel and grubx64.efi with sbsign!

#2 Post by sunrat »

Wow, what a rant! Lots of words to say not much. :D
Debian Buster will most likely support Secure boot and you can try its RC1 installer now. Secure boot is no holy grail anyway, it has already been compromised - https://www.welivesecurity.com/2018/09/ ... nit-group/

User avatar
Head_on_a_Stick
Posts: 919
Joined: Sun Mar 17, 2019 3:37 pm

Re: Secure boot forbids loading modes from...error still after signing my kernel and grubx64.efi with sbsign!

#3 Post by Head_on_a_Stick »

sunrat wrote: Sun Apr 21, 2019 8:32 am Debian Buster will most likely support Secure boot
It already does, I tested the RC1 installer a few days ago:

http://forums.debian.net/viewtopic.php?p=696683#p696683

:happy:

@OP: your rant is too dense for me to wade through but the Debian wiki has a guide for testing Secure Boot support in buster that you may be able to apply to your MX system:

https://wiki.debian.org/SecureBoot/Testing
mod note: Signature removed, please read the forum rules

User avatar
fehlix
Developer
Posts: 10310
Joined: Wed Apr 11, 2018 5:09 pm

Re: Secure boot forbids loading modes from...error still after signing my kernel and grubx64.efi with sbsign!

#4 Post by fehlix »

jmon wrote: Sun Apr 21, 2019 8:14 am how to DIY make MX Linux work with Secure Boot...
...
task of repetitvely signing EVERY module-one-by-one
You would not signed every grub modules, but you embed needed modules and sign the whole efi-grubloader with all embedded modules.
Note further: Even if your signed efi-grub loader would load, you still have to make sure the loaded kernels are signed too.
You could take Debian's signed efi-grub-loader which embeds all required modules but also requires to boot from a signed kernel. And you would mok-enrole the key as mentioned by @Head_on_a_Stick in the Debian wiki.
As MX Linux does not provide signed kernels this might be another show stopper to get secure boot with full a security chain up and running for Mx Linux.
Now what?
If you just want to get going with secure boot and current MX Linux, another approach would be, you take one of an already signed efi-grub-bootloader which allow booting into non-signed kernels.
The way I have proven that it works was to take an "older" ubuntu signed efi-grubloader which still allows to boot into non signed kernel.
IIRC, as POC I managed to secure-boot with an ubuntu signed efi-grubloader from ubuntu 18.04.(?).
:puppy:
Gigabyte Z77M-D3H, Intel Xeon E3-1240 V2 (Quad core), 32GB RAM,
GeForce GTX 770, Samsung SSD 850 EVO 500GB, Seagate Barracuda 4TB

Post Reply

Return to “MX Modified”