Secure boot signing for btrfs-efi

dcavalca commented

2024-09-03 03:05:09 +00:00

Contributor

We'd like to add btrfs-efi to the build channel for official signatures: https://src.fedoraproject.org/rpms/btrfs-efi . btrfs-efi is a btrfs filesystem driver for EFI; among other things, it would make it easier to properly support /boot on btrfs for secureboot-enabled systems.

We'd like to add btrfs-efi to the build channel for official signatures: https://src.fedoraproject.org/rpms/btrfs-efi . `btrfs-efi` is a btrfs filesystem driver for EFI; among other things, it would make it easier to properly support `/boot` on btrfs for secureboot-enabled systems.

dcavalca commented

2024-09-03 03:05:34 +00:00

Author

Contributor

cc @ngompa @salimma

ngompa commented

2024-09-03 03:17:57 +00:00

Member

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

ngompa commented

2024-09-03 03:43:47 +00:00

Member

cc: @davdunc @dbrandonjohnson

kevin commented

2024-09-03 15:20:00 +00:00

Owner

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

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

pbrobinson commented

2024-09-03 15:33:26 +00:00

Member

Is there a change associated with this?

dcavalca commented

2024-09-03 15:34:55 +00:00

Author

Contributor

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

pjones commented

2024-09-03 15:44:57 +00:00

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

ngompa commented

2024-09-03 15:51:54 +00:00

Member

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).

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).

pjones commented

2024-09-03 16:09:31 +00:00

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. 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.

ngompa commented

2024-09-03 16:10:48 +00:00

Member

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.

> 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.

pjones commented

2024-09-03 16:12:35 +00:00

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

pbrobinson commented

2024-09-03 16:25:19 +00:00

Member

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.

> 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.

ngompa commented

2024-09-03 16:29:44 +00:00

Member

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.

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.

phsmoura commented

2024-09-04 19:08:13 +00:00

Metadata Update from @phsmoura:

Issue tagged with: high-trouble, low-gain, ops

**Metadata Update from @phsmoura**: - Issue tagged with: high-trouble, low-gain, ops

ngompa referenced this issue

2026-04-02 13:57:12 +00:00

secure boot signing for systemd-boot #10765

ngompa commented

2026-04-02 13:58:08 +00:00

Member

Since we now have the infrastructure to support this for all EFI arches, can folks please look at making this work?

kevin referenced this issue

2026-04-02 17:59:58 +00:00

secure boot signing for systemd-boot #10765

kevin commented

2026-04-02 18:00:54 +00:00

Owner

So, the use here would be systemd-boot -> btrfs-efi?
Then we should sign it with the same ca as systemd-boot right?

So, the use here would be systemd-boot -> btrfs-efi? Then we should sign it with the same ca as systemd-boot right?

ngompa commented

2026-04-02 18:10:28 +00:00

Member

Currently yes, though it would be also useful for rEFInd and Sprout as well. Basically any UEFI boot manager can use it. Maybe it would make sense to have a "Fedora EFI driver CA" that shim trusts?

ngompa commented

2026-04-02 18:13:54 +00:00

Member

Insofar as SBAT stuff, @maharmstone is the developer of btrfs-efi and @dcavalca and I can talk to him about that. I'm not familiar enough with EFI driver applications to know how SBAT works with that.

Rows
Columns

Secure boot signing for btrfs-efi #12300