Recent searches
Search options
Administered by:
In the adventures of Bob's "Perfect" #Slackware install, I've been struggling to get Secure Boot working on my #Thinkpad x280.
Something seems to be preventing me from loading a custom Platform Key, while none appears loaded, and everything seems 'right' -- #SecureBoot is in Custom / Setup mode.
The unfortunate thing is ... using Secure Boot and signing kernel images and efi executables is not a common practice, and the documentation seems lacking explanations for people with my particular issue; method 1 of using `efi-updatevar` returns an error "Cannot write to PK, wrong filesystem permissions", method 2 -- updating from the #UEFI 'bios' -- is not an option on an x280, and method 3, using KeyTool.efi returns the error "Failed to update variable: (26) Security Violation".
I am wondering if there are some further setup settings that need to be adjusted to allow this operation, if perhaps my pk.auth file is incorrect in some way, if my machine was, from the factory, unable to allow custom Platform Keys, or if someone has modified it since then.
Rabbit holes are a pain in the dick, and now I'm in a position where I'm kinda 'forced' to learn a bit more about the mechanics of Secure Boot, under the hood.
Anyone got some good tips for where to start solving this puzzle?
I have been referencing:
- https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot_under_OpenRC
- https://wiki.linuxquestions.org/wiki/How_to_use_Secure_Boot_with_your_own_keys
I do not have a good link for you, but I boosted your post because I am sure that others can chime in.
@bobdobberson perhaps you'll find some inspiration from a #liveslak article:
https://alien.slackbook.org/blog/liveslak-1-8-2-re-adds-secure-boot-support/
- and the corresponding commits:
https://git.liveslak.org/liveslak/commit/?id=82d7bc751900909bcf1ea6d71ae3737454fef9d2
https://git.liveslak.org/liveslak/commit/?id=f5a3e197512428a14925376345215fcc79f73c8b
You may be missing a step on your #Slackware computer.
@alien from the first article, I think one of the tricks for grub 2.12 might be adding a custom line to the grub.cfg that disables the checking of the kernel with GPG -- in my setup, the only thing that is unencrypted at rest is the grubx64.efi binary, that I plan to sign for SB, and not require any particular signing for a kernel.
This is going to drive me nuts, as I came across that grub config option in one of the random sources I've been looking at; since I hadn't made it that far yet, I didn't think to add a note yet, and it might be that that is only required for 2.12, and I'm still using 2.06.
Let me know if the grub.cfg edit is news to you, and I'll dig it up.
@alien lol, nevermind, the first commit is the thing I was referencing.
@bobdobberson I assume you've seen this. I never went the full hog with the platform keys, but this guy seems to be right about most stuff.
https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html
@bobdobberson BTW, you sometimes have to set a BIOS password or otherwise mess around in some undocumented way before it will accept changes to secure boot. What you have may be a Lenovo-specific problem.
@kbm0 yeah, I have passwords set for that, so that should not be an issue. I've been through all the settings a few times and nothing has stood out as prohibiting this.
@bobdobberson 
If you are signing grub but not your kernel, I assume that's because you have the kernel on a LUKS device? When I tried that, I found that grub was impossibly slow at decrypting anything, especially due to LUKS key stretching. Ended up building a unified kernel image with kernel and initramfs, signing that and booting it directly from the EFI partition. Good luck however you do it.
@kbm0 grub handling your LUKS boot volume can be sped up dramatically by reducing the number of iterations used when hashing the passphrase.
`cryptsetup luksChangeKey --pbkdf-force-iterations 1000 /dev/sda3`
This makes it 'easier' to bruteforce, if you use a weak passphrase, but... we can avoid that fairly easily by making the passphrase complex, etc.
https://wiki.archlinux.org/title/GRUB/Tips_and_tricks#Speeding_up_LUKS_decryption_in_GRUB
Additionally, in my goal setup, /boot is encrypted with 1 passphrase, / is encrypted with a keyfile that lives in /boot and a separate passphrase, in case the keyfile rots, etc.
@kbm0 seems an Admin password on Lenovo systems is or can be an issue; I tried removing the passwords, and setting them to something simple, and accessing something on /sys to 'authenticate', but none of that seemed to help, either.
I had a lot of hope for a minute when I read through this; https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Using_sbkeysync
But in looking that up to share with you after-the-fact, I found another note about Lenovo systems that indicates that I need to retain the Lenovo CA certs, and can't wipe everything, and perhaps there is something preventing me from loading my platform key, and enabling secure boot, and potentially 'bricking' my system, as, apparently, the UEFI is also something that needs to be trusted by SB.
The rabbit hole continues...
@bobdobberson Yeah in theory you would hope to replace the PK, then re-sign and import any vendor DB keys which have been used to sign other parts of the system. Not sure if this always works though. Of course you can avoid all this messing with built-in keys by just using a MOK, but I guess you want to *exclude* binaries signed by Microsoft etc, and MOK won't do that.