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

["Alexander Graf via groups.io" <graf=amazon.com@groups.io>]

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.


Alex




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879




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