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

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

On Mon, 4 Dec 2023 at 13:38, Alexander Graf <graf@amazon.com> wrote:
>
>
> On 04.12.23 13:20, Gerd Hoffmann wrote:
> >    Hi,
> >
> >> (hint: You really don't want or need shim on ARM. The only reason for shim
> >> is that on most x86 desktop systems, users will have the MS keys
> >> preinstalled. The MS Secure Boot concept however is terribly broken: Any
> >> compromise of any of the MS signed binaries jeopardizes your boot chain.
> >> You're a lot better off installing *only* your distribution's key material.
> >> 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. I think we're all better off as
> community if we don't repeat the mistakes we did on x86 on ARM.
>
> 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.
>
> The same applies to RHEL-on-EC2, where you can bring your own db.
>
>
> > 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 :).
>
> Once you sorted that bit out, we can start talking about paths to remove
> shim on select x86 environments such as VMs.
>
>
> > 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. Fight the battle please, we'll all be off with an easier boot
> stack as a result :). This bug here alone already shows you why shim is
> a bad idea conceptually. Necessary in an MS dominated world, but still bad.
>
> If there are concerns around tooling differences (like mokutil), let's
> look at how we can unify/simplify the user experience instead.
>

I don't think it helps to go off on a tangent about why shim exists
and why it is so terrible, as I don't think there is actually any
disagreement about that. But now that we are, let me add my 2c as well
:-)

For the patch under discussion here, I think that Gerd's suggestion is
to have both a PCD and a QEMU variable, and use the PCD unless the
variable has a value. I'm on the fence here: I would like to
accommodate users, but adding another control that the distros are
just going to set and forget is just going to make the mess bigger.

What is even worse: arm64 system firmware will have to deal with this
as well, and disable the protocol in order to run distro installers.
And once the tightened MS requirements for NX compat come into effect,
they will have to add another workaround for this as well, and so
we'll probably end up with generations of arm64 hardware with a
'enable memory attributes protocol' option in their BIOS menus. And
guess what the default setting is likely to be?

I am quite disappointed with the complete lack of involvement from the
folks who develop and deploy shim, and instead, third parties (and
users) are the ones chasing me and people like Gerd (who work on QEMU
or EDK2 rather than shim) to clean up the mess.

If the shim developers (or anyone else) can suggest some kind of
heuristic for deciding whether a broken shim is calling into the
protocol, I'd be more than happy to add more code to avoid the need
for a QEMU command line option in the common case. But just turning it
off via a PCD or otherwise is not something I am willing to entertain.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112040): https://edk2.groups.io/g/devel/message/112040
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]
-=-=-=-=-=-=-=-=-=-=-=-