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 15:52, Gerd Hoffmann 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)?


I know of 3 categories:

1) U-Boot

https://docs.u-boot.org/en/latest/develop/uefi/uefi.html#configuring-uefi-secure-boot

The target audience for UEFI Secure Boot in U-Boot is more embedded: You 
would typically ship a system with a prepopulated db.

2) EC2

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-ami-with-uefi-secure-boot.html

Similar to the above: Whoever builds an AMI is also responsible for 
shipping a viable 'db' that matches its payload.

3) Windows ARM notebooks

As far as I remember, these do use UEFI Secure Boot, but only contain 
the 1st party Microsoft keys, no 3rd party keys. So they're like the 
cases above, but with Windows as OS target.


I'm not aware of any environment today that makes installation of db 
keys easy. But that doesn't mean that nobody uses UEFI Secure Boot :).


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


What if that shim immediately on start tries to see if it can load and 
execute another binary at the same path instead? Then you could have it 
directly jump into your real payload if that works successfully. If it 
does not, it (most likely) means the signature is wrong and you need to 
jump through the actual shim code path.


That way you get shim out of the way for the non-secure-boot and the 
distro-key-installed cases.

> 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


I'm not quite sure what you're getting at :).

First, the fundamental problem with huge dbx files is *precisely* 
because the MS key is used in too many places. Smaller set of key scope 
means smaller dbx.

Second, I think the basic concept of introducing a new abstracted 
"version" that dbx can match against is great. It would make dbx updates 
a lot more efficient. So why don't we include that concept in the UEFI spec?


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


Thank you!


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


I don't know if putting it on a standardized location is really 
necessary. If you boot with SB disabled and just as part of the 
installation process install the distro keys, everything should fall 
into place nicely, no?

For OpenStack/EC2/whatever, you don't run the installer, so you don't 
need a standardized location for it. For EC2 the target image is 
completely opaque. We don't even have (or want to have) a storage or 
file system driver to access it. That's why it's in metadata (UefiData), 
separate from the disk image.


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 (#112074): https://edk2.groups.io/g/devel/message/112074
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]
-=-=-=-=-=-=-=-=-=-=-=-