[7B] add 4 dbx hashes (2 x64, 2 ia32)

[olkorsha]

Description

4 hashes revoked, all related to previous revocation in april
Someone (hopefully not me) is going to have to update the scripts and pipelines and such to handle multiple efiauth2 files.
Going forward, each hash revoked will have its own file

[hughsie]

Hi all; what's the plan going forwards? Do I need to make fwupd changes?

[olkorsha]

Hi all; what's the plan going forwards? Do I need to make fwupd changes?

Depends, does fwupd use the EfiAuthentication2 files (e.g. amd64/DBXUpdate.bin) or the EfiSignatureDatabase files?
If EfiAuthentication2 then it'll need updates to handle 1 efiauth2 file per revoked hash going forward for KEK 2011 devices.

[hughsie]

does fwupd use the EfiAuthentication2 files (e.g. amd64/DBXUpdate.bin) or the EfiSignatureDatabase files?

The former, e.g. all these from https://github.com/fwupd/dbx-firmware/blob/main/README.md

If EfiAuthentication2 then it'll need updates to handle 1 efiauth2 file per revoked hash going forward for KEK 2011 devices.

So, we'd apply the solo dbx entries one by one in some predetermined order? Isn't that going to increase dbx failures due to nvram fragmentation? IIUC, we want to avoid writing the EFI variables as much as possible -- especially for "large" entries like the dbx. In most firmware implementations the new dbx is allocated from the unused nvram area, then the new data copied, then the old dbx is marked as unused. If the dbx grows multiple times by a few bytes each time isn't that going to exhaust the available space very quickly until some kind of nvram garbage collection -- which firmware has traditionally been very bad at doing -- some only doing when doing a "firmware factory reset"...

This also means it's possible to fail midway through the deployment, so rather than going from state A to state B we can get to some intermediate state of "nearly B" which is going to be very difficult to recover from. It's also going to be very difficult to work out what dbx versions we need to deploy for which CVE when OEMs can install the updates themselves out of the factory, and they might install the dbx entries in a different order to fwupd. This proposal goes from "this is the dbx from microsoft" to "build your own adventure".

If nothing else, fwupd doesn't "already know" how to deploy multiple dbx updates in one operation, and although this is something that we already support for the db updates -- it still requires me to update the plugin and deploy the client to end users -- which for RHEL takes ~6 months. Can we talk about a timescale of when this has to be done rather than be given a fait accompli that screws over all Linux users?