cc @ngompa @salimma

Here's a sample spec for btrfs-efi-signed that pulls the btrfs-efi binary RPMs as inputs: https://pagure.io/btrfs-efi-signed/blob/main/f/btrfs-efi-signed.spec

cc: @davdunc @dbrandonjohnson

I don't think we can currently do this due to issues with the current secureboot signing setup.

We are working on reworking it, but it's not in place yet.

See https://pagure.io/releng/issue/10765 for the systemd-boot ticket.

CC: @pjones @rharwood

Is there a change associated with this?

Not yet, but we can definitely put one up if it's useful.

Can someone explain the workflow they see this being used in?

The idea is that this would be used by EFI boot managers to be able to read a Btrfs volume, similar to what would be possible if you used edk2-ext4 to make UEFI boot managers read Ext2/3/4 volumes.

In particular, the idea is to combine it with boot managers like systemd-boot or rEFInd (which can automatically load the drivers if they're installed in a specific location on the ESP) so that they can (mostly transparently) access them like VFAT (or HFS+/APFS on Intel Macs).

What do you expect to load this driver? Right now there aren't any EFI systems where a driver loader even trusts a signature we'd put on it. I'm not seeing how Fedora signing it helps with what you're suggesting.

Additionally before we'd consider this okay, even if our signatures did carry weight with the EFI driver loaders, it would need to support .sbat revocations and have a self-test to check for its own revocation.

What do you expect to load this driver? Right now there aren't any EFI systems where a driver loader even trusts a signature we'd put on it. I'm not seeing how Fedora signing it helps with what you're suggesting.

I would expect our boot manager to load it. And that would already trust our signature.

Additionally before we'd consider this okay, even if our signatures did carry weight with the EFI driver loaders, it would need to support .sbat revocations and have a self-test to check for its own revocation.

I can add sbat data to the binaries easily enough, I suppose.

Currently we don't have an EFI driver loader in any of our bootloaders.

I would expect our boot manager to load it. And that would already trust our signature.

Normally EFI drivers are loaded by the EFI firmware, even if prompted to be loaded by a bootmgr, which means it uses the EFI infrastructure for things like verification so it would need to be signed by a key supported by the firmware which in most cases I believe it would be the MS key like shim is signed by.

Maybe not grub, but systemd-boot does. It'll load drivers installed into \EFI\systemd\drivers. As for rEFInd, it can load any that it is told to load via its configuration file stored on the ESP.