Hi,
> > > That way you at least you know who you trust. Just remove shim. Have a
> > > look
> > > at how Amazon Linux 2023 did it [2] :))
> > You are in the luxurious position to run your own distro on your own
> > platform, which makes this totally easy.
> Sure, we're cheating a bit on x86. But for ARM, the same story holds true
> for RH as well. There are a solid number of ARM systems that implement UEFI
> Secure Boot today - and none of them (that I'm aware of) provision a
> Microsoft 3rd party key.
Didn't got my hands on any such arm system.
How do you enroll the keys on those systems?
Do they offer the option to read the 'db' keys from files on distro boot
media? Or do they expect the distro boot loader (or installer) to enroll
keys and enable secure boot (which is supported by systemd-boot I think)?
> In fact, for virtual machines you're in the exact same position as EC2: If
> virt-install only provisions Red Hat Secure Boot keys by default when you
> install Fedora or RHEL guests, you've already increased your guests'
> security posture significantly.
Well, no. One problem is install media, where you really have only
one entry point (EFI/BOOT/BOOT${ARCH}.EFI) which must work under all
circumstances. Which must be shim with microsoft signature (and ideally
distro signature too) on x64.
When booting cloud images and the platform allowing for
'bring-your-own-varstore', then yes, it is simpler and doable.
> > The RH bootloader team considers shim.efi being an essential part of the
> > boot chain (to the point that the distro grub.efi throws errors with
> > secure boot being enabled and shim.efi missing), and on x86 bare metal
> > it actually is essential because hardware usually ships with only the
> > microsoft certificate enrolled.
> See above, the key (in your case) is to not treat ARM and x86 identical. And
> yes, the (downstream) shim patches for grub break normal grub secure boot
> support. But that's a bug - not a feature :).
I'm with you on that. Unfortunately the boot loader team is not.
https://bugzilla.redhat.com/show_bug.cgi?id=2108083
tl;dr: You can't boot Fedora in secure boot mode without microsoft keys
today. grub.efi refuses to work without shim.efi, and shim.efi exists
only in a microsoft-signed version (which differed from rhel were a
second, redhat-signed shim binary exists).
Oh, and the above applies to x86 only. On arm fedora shim.efi is not
signed and grub.efi is signed with the (public) redhat test keys.
> > At least they promised to sign shim with both distro and microsoft keys
> > on the next update, so I have the option to enroll the distro instead of
> > the micosoft keys in 'db' on platforms where this is possible.
>
> Shim really has no place in a world where you have a distro key enrolled.
Except for https://github.com/rhboot/shim/blob/main/SBAT.md
> Fight the battle please, we'll all be off with an easier boot stack as a
> result :).
Trust me, I had my fair share of battles already, and I still have
multiple open bug reports.
> If there are concerns around tooling differences (like mokutil), let's look
> at how we can unify/simplify the user experience instead.
IMHO it essentially it comes down to standardize a few things. Most
importantly placing the distro secure boot certificate on some
well-known location on the install media, so tooling like virt-install
can pre-load it into 'db' of the guest it is going to install.
Something similar for cloud images, so OpenStack / EC2 / whatever can do
the same.
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112044): https://edk2.groups.io/g/devel/message/112044
Mute This Topic: https://groups.io/mt/102967690/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
