Device Driver Certificate for System in SecureBoot #boot #drivers #uefi #system #secureboot
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?
Imaginative threat scenario:
When it comes to #SecureBoot some people don't want to enroll Microsoft keys because they are afraid it opens up the possibility of booting malicious boot environments.
My LUKS password is TPM sealed with PCR7 and requires a PIN. Microsoft keys enrolled.
You are a threat actor trying to decrypt my disk. You have managed to successfully boot a malicious initramfs and presented me with a LUKS prompt.
What do you do once I hit enter?
Currently shopping for ideas and opinions on how `sbctl` should approach the revocation list in Secure Boot (`dbx`).
https://github.com/Foxboron/sbctl/issues/23
Feel free to come with ideas but trying to keep things simple is the goal here.
#dailyreport #secureboot #encyption #dracut #linux #boot
#gentoo #grub #dm-crypt
I installed Gentoo GNU/Linux with full encypted root with
deattached LUKS2 header by GPG encrypted key file at
USB. :-) If you don't understand - it is perfect.
I almost gave up, but suddenly found complete guide from
"Screenager" with hack to Dracut.
It is Grub -> Dracut -> decrupt, mount -> Root.
"plymouth quit" - that is how to get access to Dracut
rd.shell.
I know three ways to boot kernel:
- kexec and chroot from installCD
- Legacy BIOS - MBR record
- UEFI - EFI stub, makes installation even more harder.
Why so much effor? 1) Because this is Ring 0 level of
security. 2) Actually, I have a very good GPG
encryption for a single file with GPG prompt outside of
Windows. I just prove to myself that I can do it.
蠡
"fwupdmgr security" on my ThinkPad T14s Gen4 running on Fedora Linux 41.
Full HSI-4 security standard with secure-boot enabled and Linux kernel in lockdown mode.
Hard disk encrypted with LUKS and the key is stored on a hardware security module (#Nitrokey 3 USB Stick) and protected by a PIN number.
Elämää kahden käyttiksen välissä:
• Secure Boot päällä virtuaalikoneet eivät käynnisty Linuxissa. Avainten allekirjoitukset?
• Secure Boot pois päältä Windows sekä herjaa siitä että vaatii BitLocker-avainta.
BitLockerista voin luopua, mutta Secure Boot olisi kiva. Virtuaalikoneiden on toimittava.
Dmitriy from @siderolabs did a couple of optimization changes to my `go-uefi` library.
Results in a reduction of their memory usage from 1.6 GiB to 80 MiB(!)
FOSDEM 25: Booting without bootloader
Grub 2 is the boot loader for most Linux distros, Systemd-boot is a fast alternative. Kernel images made bootable via EFI can boot directly.
FOSDEM 25: Booten ohne Bootloader
Grub 2 ist der Bootloader der meisten Linux-Distros, Systemd-boot eine flotte Alternative. Per EFI können bootfähig gemachte Kernel-Images direkt starten.
i'm very close to finishing my tofu/packer overhaul. the goals are twofold:
one: to configure secure boot and tpm based disk encryption, which should provide trusted boot
two: to reorganize the code as almost everything was in two huge tf files
when i'm done, i will update my public pve-talos repo for anybody to fork for their purposes
so I got official confirmation from Microsoft that, for bugs in the windows boot environment leading to Secure Boot bypass, fixes are only being backported to the PCA2023-signed bootmgr_ex, not the PCA2011-signed bootmgr.
systems running anything older than Windows 11 24H2 (I think?) are still vulnerable to “patched” bootloader bugs unless you manually install the newer bootloader; of course, if you don’t do that anyway you’re still vulnerable to downgrade attacks! and if you DO manually install the newer bootloader, you get screwed in other ways (specifically not being able to boot from older install media/backups)!
on a related note, MS updated their KB article about similar issues to add the following about when PCA2011 will be revoked for everyone:
The Enforcement Phase will not begin before January 2026, and we will give at least six months of advance warning in this article before this phase begins.
This marks the third time the Enforcement Phase has been pushed back; from “Q1 2024” to July 2024 to October 2024 to “some point after January 2026”. I suspect it will never happen for systems that were not preinstalled with, or that cannot officially run, Windows 11.
@S_Paternotte @GrapheneOS meanwhile I see #OpenAI literally using falsified #UserAgent|s and #DDoS'ing clients at work so hard I have to ban entire ASNs and /10 networks just because they ca't be assed to respect the robots.txt and refuse to accept beibg given 403 errors.
-Needless to say banning #GrapheneOS which are by far the most security-focussed and most diligent in terms of #Aftermarket-#Android-#ROM|s whilst not banning #outdated Android versions is like banning a "#SecureBoot|ed" #UbuntuLTS or #OpenBSD installation and going out of one's way to brick #Wine whilst still supporting #WindowsXP in 2025!
@ESETresearch @smolar_m thanks for the post and research.
And yes I refuse to call it "#SecureBoot" because it is not secure by #Microsoft's own admission - otherwise they would've relied on it on the #XboxOne and not just the #Xbox360 !
Nice, it looks like there's going to be a #SecureBoot-signed version of #systemdboot in #DebianTrixie.
https://packages.debian.org/trixie/systemd-boot-efi-amd64-signed
This was a fascinating read https://neodyme.io/en/blog/bitlocker_screwed_without_a_screwdriver/#teaser
Microsoft patches Windows to eliminate Secure Boot bypass threat - For the past seven months—and likely longer—an industry-wide standard that... - https://arstechnica.com/security/2025/01/microsoft-patches-windows-to-eliminate-secure-boot-bypass-threat/ #secureboot #security #firmware #windows #biz #uefi
(plz hire me) 
