Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • How do desktop Linux distros avoid attackers from rolling back the operating system to a vulnerable, but signed version?
    by charcircuit
  • This is not an issue specific to Linux, Windows installations can be downgraded as well. As for the mechanism, UEFI devices, alongside key updates, also get revocation list updates.
    by Sateallia
  • Some laptops allow Custom Mode in UEFI setup menu. Then you can clear these keys and load your own. On Linux etc. you can that way enable secure boot without MS keys.

    Not all devices support it, so choose wisely.

    by saidnooneever
  • Well, it seems like keeping secure boot disabled was gonna help me in the future haha

    I know it is not recommended but the options to have my own keys seemed a bit of a hack than a solution.

    by h4kunamata
  • I'm surprised more people aren't freaking out about this. It seems likely a whole lot of Linux machines are going to fail to reboot in the next few months. The problem affects VMs too. I was grateful Proxmox put a little warning in its hypervisor GUI with a button to press to fix the BIOS of its VMs.

    Secure Boot has been deeply broken for years, not providing meaningful security on most consumer machines.

    by NelsonMinar
  • Why has it been broken? I’m running secure boot on all my machines with my own certs. It works fine.

    Whatever ms and hp / Lenovo do with their certs doesn’t affect me, since I only have my certs installed. Except on a single machine whose purpose is running windows, but it’s not on the critical path for my job.

    by vladvasiliu
  • I don't have any numbers to prove it, but I'd say the reason Linux users aren't freaking out is because the vast majority of them would've have disabled Secure Boot. In fact, many guides and videos from popular Youtubers[1] explicitly state to disable Secure Boot.

    As for VMs, whilst the problem indeed affects them too, the reality is that most hypervisors - even commercial ones - don't actually enable Secure Boot by default, you'd have to go really out of your way to enable it for a VM.

    [1] https://www.youtube.com/watch?v=_Ua-d9OeUOg&t=253

    by d3Xt3r
  • Existing systems are going to continue to boot. The expiry date is enforced for signing new binaries, not for deciding whether an already signed binary is allowed to boot (barring buggy firmware).

    https://mjg59.dreamwidth.org/72892.html (Secure boot certificate rollover is real but probably won't hurt you)

    https://wiki.debian.org/SecureBoot/CAChanges#OMG.21.21.21_Wi...

    by epakai
  • Discussed at the time (of the article):

    Linux and Secure Boot certificate expiration - https://news.ycombinator.com/item?id=44601045 - July 2025 (265 comments)

    by dang
  • > triggering a "de-fragmentation" of the available efivar space so that there's enough contiguous space to deploy the update.

    I didn't even realize this could be a problem despite the next paragraph implying it's very well known.

    by 0xCMP
  • I saw 2-3 flavors of this news. None of them include a basic “how do I check if I need to do anything” guide that a linux newbie can do.
    by laserbeam
  • https://wiki.debian.org/SecureBoot/CAChanges#What_should_I_d...
    by epakai
  • On my Fedora machine I was able to run

        mokutil --db --short
    To check my secure boot keys. As long as there's 2023 Microsoft keys you should be fine. Otherwise, my understanding is that you just need to update your firmware, but please somebody correct me if I'm wrong.
    by Hugsbox
  • Last time I installed Arch, I put Secure Boot in setup mode and enrolled by own keys. The idea of using someone else's keys seems absurd.
    by drnick1
  • I've honestly always kept secure boot off on my machines (which also use Arch). I don't really feel like the level of threat from someone (or me, by accident) booting an image I don't want them to on my hardware is particularly worth the hassle it brings; nobody else should ever be using my machines in the first place, and if they are, I'm going to have larger issues than what OS they decide to try to boot.
    by saghm
  • Do note that being able to completely remove MS keys is highly dependent on your mainboard. Not in the sense of if they allow you to do it (I think most if not all DIY boards allow you to), but if you will be able to boot afterwards.

    I (soft?)bricked a mainboard and it doesn't want to boot anymore after I removed the MS keys. The worst part is, that it has a dualBIOS and no active switch to change between them, only their own "I'll change when I see issues"... well you can guess how well that worked out (and I am not able to get it to clear CMOS for some reason).

    by NekkoDroid
  • > The KEK updates are going out at ~98% success, and db update is ~99% success

    glad to see the opt in fwupd analytics being so useful for something like this

    Not envious of the running around contacting vendors they must of been doing on such short order.

    by its-summertime
  • They left out the steps to update it. I made a rough attempt at a document for this. [1] Please let me know if I missed a validation step. I have done this on six machines but they were all Linux. Not tested on BSD.

    Archive [2] in the event I was too aggressive in blocking bots.

    [Edit] I should also include this [3] thread for completeness sake. Some people people were playing with a shim work around but it looks like a lot of unnecessary complexity and fragility to me.

    [1] - https://nochan.net/b/Internet-Crap/20260621-Update-Secure-Bo...

    [2] - https://archive.is/ml3jv

    [3] - https://www.reddit.com/r/archlinux/comments/1pvw6td/grub_shi...

    by Bender
  • Found this on one machine. Key expires in 5 days. System runs Linux only and has never booted Windows, ever. Secure boot may be off.

        SHA1 Fingerprint: 46:de:f6:3b:5c:e6:1c:f8:ba:0d:e2:e6:63:9c:10:19:d0:ed:14:f3
    Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            61:08:d3:c4:00:00:00:00:00:04
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
        Validity
            Not Before: Jun 27 21:22:45 2011 GMT
            Not After : Jun 27 21:32:45 2026 GMT
        Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011
    by Animats
  • More recent archive [1]

    [1] - https://archive.is/dPFuq

    by Bender
  • FYI your server returns Brotli encoded content, even if the request has only Accept-Encoding: gzip, deflate, zstd - making it unreadable in for me (Firefox on Fedora).
    by 0l