Linux users may face yet another hurdle related to Secure Boot when the Microsoft-signed key used by many distributions to support the firmware-based security feature expires on September 11, leaving users at the mercy of distribution from OEMs, and systems possibly not receiving a necessary firmware update.

As LWN reported (paywall) that Microsoft will stop using the expiring key to sign the shim in September. "But the replacement key, which has been available since 2023, may not be installed on many systems; worse yet, it may require the hardware vendor to issue an update for the system firmware, which may or may not happen," LWN said. "It seems that the vast majority of systems will not be lost in the shuffle, but it may require extra work from distributors and users."

The report said manufacturers could add support for the new key in a full firmware update or by updating the KEK database. The former assumes that manufacturers would be interested in distributing a firmware update for a wide variety of products so a small percentage of their users could use Secure Boot with a non-Windows OS; the latter is an unproven mechanism that isn't guaranteed to work on all devices. Both seem likely to leave at least some people to figure out a solution on their own.

all 51 comments

sorted by: hot top controversial new old
[–] 63 points 1 year ago (7 children)

If you start with a reasonably recent Windows machine, there's a TPM with secure boot (and MS keys) enabled. If setting up dualboot Windows/Linux, you're going through BIOS/UEFI, so expiring keys will affect you. Booting into Windows and doing an update should fix the problem.

If you disabled secureboot/FDE, then installed Linux and left it at that, you should be OK.

But under Linux, those who reenable fulldisk encryption or secure boot via the TPM may be impacted by this, and since they've removed Windows, they may be screwed: https://allthings.how/how-to-enable-tpm-encryption-and-secure-boot-on-ubuntu-24-04/

  • source
  • hideshow 7 child comments
  • [–] 17 points 1 year ago (3 children)

    So why can't Linux just do whatever the Windows update does?

  • source
  • parent
  • hideshow 3 child comments
  • [–] 34 points 1 year ago (1 child)

    Tools to do that exists. fwupd is a tool to update firmwares. I just tested it on a thinkpad and went from 351 keys to 518 secureboot keys.

    GNOME Software also uses fwupd, that should take care of a good chunk of users.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 6 points 1 year ago

    The Windows update loads a chain of trust that tells the bootloader the device is OK and your version of Windows is real and your full-disk-encryption is fine. Linux folks don't have (or need) all that. They can create their own chain of trust if they want, but they don't have read/write access to the Microsoft one.

    If they did, we would be reading a completely different article starting with why the world was on fire.

  • source
  • parent
  • [–] 5 points 1 year ago* (2 children)

    So my framework 16 that has never seen Windows running FedoraKDE with FDE (but not auto-unlock, typed pass every boot) enabled is going to explode?

    Half kidding, but like, should I disable secure boot or something? Run fwupd?

  • source
  • parent
  • hideshow 2 child comments
  • [–] 5 points 1 year ago (1 child)

    If it's never seen Windows you may be fine.

    The problem is mostly for systems that dual-boot or had Windows at one point, but got Linux installed on top. A lot of people use old Lenovo, HP, or Dell computers and repurpose them for Linux. Those are the ones that may get bit.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 1 year ago

    Ordered it plain, added flavor myself (FedoraKDE, as I mentioned lol).

    I do have a few spare old laptops with linux that used to be windows, but tbh the critical one is my main, the others don't really need secure boot as long as they don't get bricked.

  • source
  • parent
  • [+] 42 points 1 year ago (18 children)
  • [–] 72 points 1 year ago (2 children)

    From https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/managing_monitoring_and_updating_the_kernel/signing-a-kernel-and-modules-for-secure-boot_managing-monitoring-and-updating-the-kernel: "In addition, the signed first-stage boot loader and the signed kernel include embedded Red Hat public keys. These signed executable binaries and embedded keys enable RHEL 8 to install, boot, and run with the Microsoft UEFI Secure Boot Certification Authority keys. These keys are provided by the UEFI firmware on systems that support UEFI Secure Boot."

    Basically the Microsoft keys are ones that the firmware vendor (motherboard or chip manufacturer) recognizes as secure by default (via CA validation). You can override them. It's not a Linux issue but a hardware-vendor-defaulting-to-Microsoft issue.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 5 points 1 year ago (1 child)

    If security is the actual I'd even argue you SHOULD over ride them. It's like the default password on your home router

  • source
  • parent
  • hideshow 1 child comment
  • [–] 8 points 1 year ago

    You're not wrong, but unfortunately it's not simple and can brick your motherboard if you make a mistake. I wouldn't expect the average Linux user to do it these days. It can also depend on the hardware. If they don't expose any ability to change the keys you're stuck.

  • source
  • parent
  • [–] 36 points 1 year ago (12 children)

    Microsoft has spent the time and money to get their key added to the silicone of the BIOS chips on PC hardware. Everyone else needs to get their key signed by Microsoft, including Red Hat and Canonical.

  • source
  • parent
  • hideshow 12 child comments
  • [–] 19 points 1 year ago (10 children)
  • [–] 6 points 1 year ago (8 children)
  • [–] 4 points 1 year ago (5 children)
  • [–] 16 points 1 year ago

    Every manufacturer includes the Microsoft secure boot key in their firmware. I'm not sure if any manufacturer includes a Linux-specific key. So Microsoft signed a bootloader with their key, enabling secure boot to work with Linux without having to load another key onto every device.

  • source
  • parent
  • [–] 10 points 1 year ago

    AFAIK it's not necessarily about Linux using Microsoft keys, it's more about Microsoft shoe-horning their bullshit into everything they possibly can, including at the hardware/firmware level.

  • source
  • parent
  • [–] 41 points 1 year ago* (last edited 1 year ago) (11 children)

    can i just not use secure boot?

  • source
  • hideshow 11 child comments
  • [–] 57 points 1 year ago

    That's what I do. I never enabled it based on the assumption that because it's a Microsoft thing, it would eventually fuck me over in some way. That attitude has served me well for may years lol.

  • source
  • parent
  • [–] 15 points 1 year ago (9 children)

    You can but then you don’t have secure boot.

  • source
  • parent
  • hideshow 9 child comments
  • [–] 16 points 1 year ago (8 children)
  • [–] 29 points 1 year ago* (7 children)

    If you don’t care about boot chain attacks it isn’t bad at all.

    If you do care about boot chain attacks it’s bad because it allows someone to replace things like the efi binaries, grub, or your kernel with backdoor-ed versions and there would be no way to detect this from the running system.

    Secure boot checks for this stuff. You can read more here:

    https://access.redhat.com/articles/5254641

  • source
  • parent
  • hideshow 7 child comments
  • [–] 17 points 1 year ago (6 children)

    But if secure boot happens to brick your system forever because of this expiring key thing, is that worse than a boot chain attack?

  • source
  • parent
  • hideshow 6 child comments
  • [–] 13 points 1 year ago* (5 children)

    It won’t brick your system forever??? You just turn it off in your bios. Then you have no secure boot. Just like it was never there.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 6 points 1 year ago* (4 children)

    Shouldn't a system that was set up with Secure Boot refuse to start if it were disabled? Otherwise there wouldn't be any protection against these attacks.

    I don't think setting up the system again is a simple remedy to having problems with this feature.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 14 points 1 year ago* (last edited 1 year ago) (3 children)

    It won’t refuse to boot. It’s just that any automatic metric based decryption won’t work.

    If you are using a TPM to automatically unlock luks and also manually removed the password backup before hand you could lose your data forever. That is true.

    But if you kept the password based decryption stuff you could still manually unlock stuff. Just like secure boot was never there.

    The difference would be that there could be no secure attestation that the kernel count trust/use without secure boot.

    Like secure boot is really cool on Linux if you learn about it. Like sbctl alone is great for verifying backups and stuff.

    I recommend reading through the arch wiki if you want to learn more. It covers a lot of stuff. https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot

  • source
  • parent
  • hideshow 3 child comments
  • [–] 4 points 1 year ago (2 children)

    Turning off secure boot wont turn off your TPM, it just turns off all the signature verifications. Your TPM still stores the decryption keys and you can still decrypt your data.

    Now if you do a UEFI/BIOS update without disabling your encryption while using a TPM, and dont have password decryption as a backup, yes, you could potentially lose access to your data.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 4 points 1 year ago (1 child)

    It won't turn off your TPM, but if you've set it up correctly (by using PCR7), the TPM won't allow decrypting your data without secure boot.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 27 points 1 year ago (1 child)

    I'm fairly new to Linux, so I'm wondering if someone could confirm.

    I ran bootctl status in the terminal and saw "Secure Boot: disabled". That means I'm in the clear, right?

  • source
  • hideshow 1 child comment
  • [–] 9 points 1 year ago

    Microsoft's Secure Boot UEFI bootloader signing key expires in September, posing problems for Linux users

  • source
  • [–] 5 points 1 year ago

    It would appear that major distros like RedHat/Fedora, Ubuntu, Debian, etc are not overly concerned at this point. I would suspect that if they truely feared this happening, they would be moving very quickly to create patches or work arounds for this problem.

  • source
  • [–] 5 points 1 year ago

    I've learned several new commands from this thread and am grateful to all of you who've taught me them.

  • source
  • [–] 4 points 1 year ago (2 children)

    What happens on Windows if the motherboard is old and do not have the 2023 key in its UEFI?

  • source
  • hideshow 2 child comments
  • [–] 9 points 1 year ago* (last edited 1 year ago) (1 child)

    Then it can't be booted with new media. Microsoft has been very, very slow with the automatic rollout of their own key updates, and made just about no progress over the past two years. It's been manual updates + newly produced systems only.

    The trick here is that they have a key-exchange-key that can be used to update the other keys. That doesn't expire (or rather, not in a meaningful way). But, a Windows image is still only going to boot on a system that trusts the key that was used for it. If you make a Windows image on a 2011 system now, it's going to be signed with the 2011 key, and it won't boot on a system that distrusts that key. The same is true in reverse.

    Their key update documentation is all available and some enterprises have been on the new key for a while, but it's a lot of manual work and a lot of problems have popped up, most documented in there. How they're going to roll this out automatically to normal users isn't obvious to me. There's technically nothing stopping a system from trusting both the 2011 and 2023 keys, and I wouldn't be entirely surprised if they end up never pushing the 2011 revocation.

    The keys they use for their own OS don't truly expire until late 2026, and I expect they'll do their best to delay it until then, but the next time they have to update their boot manager is going to be painful and introduce all kinds of new problems.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 4 points 1 year ago (3 children)

    So my old Lenovo x220 that started as Windows and since then I wiped and installed pop os with full disk encryption is going to have a problem?

  • source
  • hideshow 3 child comments
  • [–] 7 points 1 year ago (2 children)

    Secure boot will fail validation. You can still boot it anyway by disabling secure boot. You just lose a layer of security. You can manually sign boot files yourself and add the relevant certificate to the motherboard firmware database. Assuming it lets you.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 1 year ago (1 child)

    I see, I'm just a novice at Linux and this seems complicated. Is there a good tutorial somewhere? Otherwise I might just disable secure boot

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 1 year ago*

    Sorry for delay.

    Install sbsigntool

    Create Certificate:

    openssl x509 -outform der -in cacert.pem -out certificate.crt
    

    The resulting certificate.crt is what will be used to verify the signature of the EFI binary. You will import this into the motherboards firmware database.

    Sign EFI Binary:

    sbsign --key cakey.pem --cert cacert.pem bootx64.efi --output BOOTX64.efi
    

    After you sign the boot file, reboot into the firmware and import the certificate. Reboot normally and secure boot should work without issue.

  • source
  • parent
  • 13 comments in c/linux@programming.dev view that post
    [–] 24 points 1 year ago

    manufacturers could add support for the new key by updating the KEK database

    Oh right, the KEK database. They are literally trolling us aren't they.

  • source
  • [–] 17 points 1 year ago (7 children)

    Not if you disable it, "secure boot" is a joke anyway.

  • source
  • hideshow 7 child comments
  • [–] 26 points 1 year ago* (4 children)

    I mean, Secure Boot does actually help defend against evil maid attacks if paired with FDE. Someone can't just fuck with your /boot (CVE-2016-4484 nonwithstanding) to do naughty things with your system if you have Secure Boot enabled. Does that fit with most people's threat model? I dunno, probably not. It does actually do something useful though.

    My work computer has it enabled and I feel better for it. The issue described in the article is easily dealt with if you just keep up with your firmware updates using fwupd.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 3 points 1 year ago (1 child)
  • [–] 2 points 1 year ago (1 child)

    If you use linux and are dependant on M$, youre doing it wrong

  • source
  • hideshow 1 child comment