Installers

Posted Jul 16, 2025 22:03 UTC (Wed) by comex (subscriber, #71521)
Parent article: Linux and Secure Boot certificate expiration

The article focuses mostly on existing Linux installs. But what about new ones? What happens if you don’t have a working OS, your firmware only has the old keys, and you try to boot from new Linux installation media – or for that matter new Windows installation media? It sounds like the firmware should refuse to run the installer.

Does UEFI have some magic system where the firmware can update its keys from the install media before actually running the installer? Or are you just out of luck unless you turn off Secure Boot?

Installers

Posted Jul 17, 2025 1:22 UTC (Thu) by jreiser (subscriber, #11027) [Link]

Many ASUS motherboards within the last several years can update the board firmware directly from a file on USB flash memory (in exFAT format) without booting or using any OS at all.

Installers

Posted Jul 17, 2025 11:00 UTC (Thu) by jengelh (guest, #33263) [Link] (1 responses)

Shouldn't firmwares allow you to manually input keys? Then you could add a current one, and then boot off a current OS.

Installers

Posted Jul 18, 2025 6:50 UTC (Fri) by kraxel (subscriber, #49444) [Link]

Some firmwares offer that functionality somewhere in the firmware setup menus. Others do not. And even for those who do there is no standard way to do so, so it is pretty hard to support that workflow.

BTW: Microsoft has released signed DB updates which add the 2023 code signing keys meanwhile.
https://github.com/microsoft/secureboot_objects/tree/main...
They are signed with the old (2011) KEK key, so there is no need to enroll the new (2023) KEK key to apply those updates.

These can be applied by standard EFI variable updates, using the efi-updatevar utility for example. I expect fwupd will support that soon too.

Installers

Posted Jul 18, 2025 13:50 UTC (Fri) by pjones (subscriber, #31722) [Link]

Our (Fedora, etc) plan right now is to make special remediation boot media, so you can boot it with an older bootloader and it'll run fwupd to update the enrolled certificates. Obviously even that can only be so successful.

We're also going to try some experiments with making that a secondary boot entry on the primary media, with the hopes that at least some firmwares will correctly attempt it after the newer boot target, but it's yet to be seen how effective that will be. We'll also do our best to make sure EDK2 supports that correctly, and try to get Red Hat's hardware partners to make sure they have that support.