Add a FuEfivars class that can be used to set up a test framework

[hughsie]

This allows us to create a FuDummyEfivars and then test various UEFI methods without reading and writing to the filesystem.

Type of pull request:

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

[superm1]

Maybe a dumb question; but why not umockdev? Can't we just mock the directory with the variables instead of a whole backend?

[hughsie]

Can't we just mock the directory with the variables

Not a dumb question at all; I'm reimplementing a bit of efibootmgr that means we can do A/B updates for bootloader components -- and I need something I can set up in half a dozen different configurations and then examine the steps -- doing things like simulating a reboot (clearing BootNext for example).

[superm1]

I'm reimplementing a bit of efibootmgr that means we can do A/B updates for bootloader components

As in fwupd does the A/B updates of bootloader components? Like part of something like Silverblue? Might want to hear more of the big picture here.

I (of course naively) view GRUB as on the general chopping block a few years from now and UKI's taking over.

and I need something I can set up in half a dozen different configurations and then examine the steps -- doing things like simulating a reboot (clearing BootNext for example).

To me; this feels a safer to do with umockdev. You don't have to worry about implementation bugs that only show up in real environment.

[hughsie]

As in fwupd does the A/B updates of bootloader components?

Yes, something like that. I think the idea is that we have something like /usr/lib/firmware.d where we dump shim.efi, and grub.efi -- and in the medium term future replacing grub.efi with nmbl.efi -- which is the not-a-bootloader-tiny-kernel-that-can-kexec new thing that Red Hat is working on for the cases where we need a bit more than just booting kernel-uki. We then copy /usr/lib/firmware.d into the ESP with a fallback using EFI vars so that we can do A/B updates of all the early-boot stuff. e.g. something like:

I (of course naively) view GRUB as on the general chopping block a few years from now and UKI's taking over.

Yes, I think that's fair. nmbl is basically "we don't need a bootloader"

To me; this feels a safer to do with umockdev.

Let me show you the tests -- then maybe you might see how we're peeking into the EFI variables. The other thing having "an object" lets you have is caching; so we don't have to hit either efivarfs or the filesystem repeatedly -- e.g. we put a single hashtable in fu-efivars.c and we get it for all the windows/linux/freebsd/dummy implementations.

[superm1]

We then copy /usr/lib/firmware.d into the ESP with a fallback using EFI vars so that we can do A/B updates of all the early-boot stuff. e.g. something like:

Something I want to caution in this design is the optimism in use of switching BootXXXX variables. Don't underestimate the assumptions that vendors have made in their BIOS for their boot manager to 'auto-add' entries for common paths. Think like how we have Linux-Firmware-Updater for Lenovo and Linux Firmware Updater for everyone else?
Just this past month BIOS for AMD internal reference systems nominally testing Ubuntu got stuck in a boot loop because Ubuntu 23.10 -> Ubuntu 24.04 switched from ubuntu to Ubuntu 🤦

So I would think it's generally safer to keep a single boot entry and instead iterate on another variable or a flat file on the filesystem to decide what "shim" loads. But if you're envisioning swapping shim that's another story and this may be inevitable.

Anyway; that's generally divergent, I get the big picture now.

Yes, I think that's fair. nmbl is basically "we don't need a bootloader"

👍

Let me show you the tests -- then maybe you might see how we're peeking into the EFI variables. The other thing having "an object" lets you have is caching; so we don't have to hit either efivarfs or the filesystem repeatedly -- e.g. we put a single hashtable in fu-efivars.c and we get it for all the windows/linux/freebsd/dummy implementations.

Yeah; I could see caching increases speed of tests by a magnitude. I guess you envision enough tests to justify the improvement?

[hughsie]

So I would think it's generally safer to keep a single boot entry

We actually tested that; we saw a few [old] systems doing horrible things when modifying the active boot entry.

got stuck in a boot loop

Ohh interesting; can you share the root cause? i.e. that's exactly the kind of thing I want to write tests for.

I guess you envision enough tests to justify the improvement?

I think there's a lot of broken hardware, and I think we'll need the ability to do various insane things to the variable.

[superm1]

Ohh interesting; can you share the root cause? i.e. that's exactly the kind of thing I want to write tests for.

Heuristics associated with mucking with boot order. The fact that this BIOS team did it and it caused problems means it's probably done by others too. I think that a test case confirming that the expected entries are still in the same position in the boot order would catch it.

I think there's a lot of broken hardware, and I think we'll need the ability to do various insane things to the variable.

It's interesting to think of fwupd as critical path here for UKIs because these are traditionally "distribution" provided components. Do you think LVFS would be how UKIs get rolled out then?

[hughsie]

Do you think LVFS would be how UKIs get rolled out then

I don't think so, but I think the SBAT (and microsoft thing) will be in a future fwupd release ;)

[superm1]

I'm happy with this once tests are pasing.