Em qua., 9 de jul. de 2025, 10:38, Richard Hughes via devel < devel@lists.fedoraproject.org> escreveu:
> 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. > This is interesting, Neal mentioned earlier that the shim is currently only signed with the 2011 and Microsoft will only start singing with the new CA when the old one is close to expiring (9 month earlier I think?). So I would guess for some OEMs we could have systems with only the new cert and for the ones with the old one one we would need both the legacy and the newer one at the same time unless we want to risk breaking stuff. Of course waiting seems to be an option as well. > 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. > Good point about the firmware age (which I assume is based on last update). Devices from the Windows 8(.1)-era come to mind and might have most issues. While probably Windows 10 and 11-era devices might either still receive BIOS updates or at very least have a not so buggy last firmware. > 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 --- Mateus Rodrigues Costa > >
-- _______________________________________________ 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
