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

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.

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 #SecureBoot bypass threat
#security #boot

https://arstechnica.com/security/2025/01/microsoft-patches-windows-to-eliminate-secure-boot-bypass-threat/

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

Widely used DNA sequencer still doesn’t enforce Secure Boot - In 2012, an industry-wide coalition of hardware and software makers adopte... - https://arstechnica.com/security/2025/01/widely-used-dna-sequencer-still-doesnt-enforce-secure-boot/ #dnasequencer #secureboot #security #firmware #illumina #iseq100 #biz&it

Given the long lifetime of automotive ECUs, pretty cool to see NXP's I.MX 94 family of automotive chips supports secure boot with post-quantum cryptography.
https://www.nxp.com/company/about-nxp/newsroom/NW-NXP-NEW-IMX94-APPLICATIONS-PROCESSORS

Do you feel like secure boot has done anything to enhance your own personal security, keeping in mind the threat models you yourself worry about?

Or has it been more of a nuisance to you than a help?

Consumer desktop/laptop perspectives only please.

systemd-ukify: Unified Kernel Image (UKI) für UEFI Secure Boot mit YubiKey signieren

https://www.codingblatt.de/secure-boot-systemd-ukify-yubikey-signieren/

If your #PC can run #Windows11, it can run #24H2 (also known as the Windows 11 2024 Update). That means you need a fairly recent #CPU and a #TPM 2.0 security chip. Beyond those, the absolute minimum hardware requirements are a 1GHz 2-core CPU, 4GB of #RAM, 64GB of disk space, and #SecureBoot capability.

What’s New in the Windows 11 24H2 Update?
https://www.msn.com/en-gb/news/techandscience/what-s-new-in-the-windows-11-2024-update/ar-AA1rx4Cy

Secure Boot-neutering PKfail debacle is more prevalent than anyone knew - Enlarge (credit: Getty Images)

A supply chain failure that com... - https://arstechnica.com/?p=2050182 #platformkeys #secureboot #security #rootkits #biz⁢ #pkfail #uefi

Not sure if anyone else has mentioned this, but wanted to add a specific data point to the #Linux and #Windows dualboot problem: it affects USB installs too. Makes sense it covers all bootable media, but experiencing it firsthand kind of sucked. Kind of a doh moment.

I have live #Kali and #tails sticks that won’t boot on the Windows machine (get the SBAT error).

Disabling Secure Boot allows it to boot (naturally, it will also boot if I plug it into my Linux machine). The temporary fix from #Microsoft does work. As a note for TAILS users, you can’t run mokutils as sudo (which is needed) unless you enable setting administrator password on boot.

#Microsoft confirms August updates break #Linux boot in dual-boot systems

If you've already updated, then ther best way to get your impacted system running apparently is to disable Secure Boot, install your Linux distro, and re-enable Secure Boot.

Microsoft is still investigating.

#windows #secureboot

https://www.bleepingcomputer.com/news/microsoft/microsoft-confirms-august-updates-break-linux-boot-in-dual-boot-systems/

I've found a lot of conflicting and confusing reports about the #SecureBoot issue caused by a Microsoft update, so here's my relatively informed take about it.

Spoilers: this isn't an issue with GRUB, but with another less known bootloader called shim. GRUB can also be affected though. So let's talk about how the bootchain of a #Linux distro works and what happened to it. 1/11

Tuesday’s update left #DualBoot devices—meaning those configured to run both #Windows and #Linux—no longer able to boot into the latter when #SecureBoot was enforced.

When users tried to load Linux, they received the message: “Verifying shim SBAT data failed: Security Policy Violation. Something has gone seriously wrong".

“Something has gone seriously wrong,” dual-boot systems warn after #Microsoft update
https://arstechnica.com/security/2024/08/a-patch-microsoft-spent-2-years-preparing-is-making-a-mess-for-some-linux-users/