Re: [edk2-devel] [PATCH] ArmVirtPkg: Allow EFI memory attributes protocol to be disabled

["Ard Biesheuvel" <ardb@kernel.org>]

On Mon, 4 Dec 2023 at 15:52, Gerd Hoffmann <kraxel@redhat.com> wrote:
>
>   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.
>

So what is holding Fedora back from providing a fixed shim binary if
it doesn't need to be signed by Microsoft? And also, the only
problematic binary in the boot chain appears to be fbaa64.efi - that
one could be fixed as well, by using 4k aligned executable sections.

To be honest (and I know I am preaching to the choir here), the more i
learn about this, the less I am inclined to make *any* accommodations
whatsoever, given that the boot loader team obviously does not give a
shit about their crappy boot chain.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112046): https://edk2.groups.io/g/devel/message/112046
Mute This Topic: https://groups.io/mt/102967690/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-