uefi-sbat: Add a new plugin that can apply revocations to SbatLevelRT

[hughsie]

Type of pull request:

• New plugin (Please include new plugin checklist)
• Code fix
• Feature
• Documentation

[hughsie]

@superm1 no plugin code yet, I wanted a sanity check from @vathpela before writing a demo.

[hughsie]

Okay, now this works for me. For testing I've been using:

# ./src/fwupdtool --plugins uefi-sbat  -vv install-blob revocations.efi.signed
# ./src/fwupdtool --plugins uefi-sbat  -vv reboot-cleanup

The former loading on revocations.efi to the ESP in the same directory as the currently booted shim.efi (mounting the ESP as required). On next reboot it removes the revocations.efi file.

To test we're refusing to deploy the new SBAT policy if any of the detected shim binaries are too old, you can do:

# fwupdtool firmware-build ../plugins/uefi-sbat/revocation.builder.xml revocation.efi
# fwupdtool --plugins uefi-sbat  -vv install-blob revocation.efi
SBAT level is too old on /boot/efi/EFI/fedora/grubx64.efi: ESP file /boot/efi/EFI/fedora/shimx64.efi has SBAT entry sbat v1, but revocation has v2

[jsetje]

Looking at the rest of the new code, I'm a bit confused what the "firmware" is in this context? I assume it would be a revocations.efi blob that has an automatic payload? Edit: I'm happy to expand that implementation a bit if that's helpful. I think I've been convinced that being able to deliver separate SbatLevel and SkuSi binaries so that combinations can be selected to be applied on a single reboot is useful.

[vathpela]

lgtm, but I can't really review things like "is it correct with your plugin architecture". So I'm assuming, since you've tested it, that on that level it's correct.