On Wednesday, 9 July 2025 at 09:52, Daniel P. Berrangé <berra...@redhat.com> wrote: > Historically fwupd wasn't able to cope with this, but recent releases > have been enhanced to handle the updates that Linux users will need > to see, which should mitigate the worst of the impact. There's a > reasonable overview of the situation here: > https://fwupd.github.io/libfwupdplugin/uefi-db.html
Agreed -- I was about to add a link to that exact page. > I'm unclear if fwupd would push the /old/ SB certs out to new HW which > only has the new SB certs - i'm guessing probably not ? We wouldn't be able to, we'd have to have a KEK *update* which included the old db key -- which vendors won't do. The tl;dr: is: * You might get a "BIOS" update that adds the new db, otherwise * You might get a new KEK update (this is per-vendor, so only vendors cooperating with Microsoft have updates available -- as more get added I'll add them to the LVFS) * Once you've deployed the new KEK (and rebooted) you should get the new db update too (shared between vendors) The KEK updates are going out at ~98% success, and db update is ~99% success -- but even 1% multiplied by millions of people is a fair few failures to deploy -- the "failed to write efivarfs" thing. What fixes it for some people is rebooting and clearing the BIOS to factory defaults -- this has the effect of triggering a "de-fragmentation" of the available efivar space so that there's enough contiguous space to deploy the update. The older your BIOS the more likely you are to hit this. In the cases where even a factory default reset doesn't fix it, it's probably because the system vendor never actually tested if the db update works -- usually the more you pay for the system the more QA for things like this was done. In the pathological case at least one vendor has lost the private key used for signing their PK, so they're having to issue firmware updates to replace the PK on the running system -- which could be a terrible idea from an attestation point of view. Those kind of vendors are also not the kind of vendors that usually issue bios updates (usually because of "cost") so the solution there is to turn off secure boot. If you're running a 7 year old system firmware then UEFI secure boot certificates are probably quite low on your compliance list. Richard. -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
