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

["Gerd Hoffmann" <kraxel@redhat.com>]

  Hi,

> I know of 3 categories:
> 
> 1) U-Boot
> 2) EC2
> 3) Windows ARM notebooks

Thanks.

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

One more possible code path.  I have my doubts that (a) the shim
maintainers like the idea, and (b) that it actually improves the overall
situation.

Also note that it isn't a fixed binary.  While grub.efi is the default
you can pass something else on the command line, for example fwupd.efi
or an UKI (unified kernel image).  Also depending on circumstances shim
decides to load fallback,efi or mokmanager.efi instead of grub.efi.  So
it's more complex that "try load grub.efi using standard efi protocols
and if that works I'm done".

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

Not sure what the status of this is, whenever it is just some kind of
agreement between shim maintainers and microsoft, trying to keep dbx
grow under control, or whenever there are any plans to add that to the
uefi specs.  Peter?

Adding that to the uefi specs (and subsequently implement it in edk2)
has the advantage that it wouldn't depend on shim.efi, and have the
drawback that it'll take ages to have an effect due to the firmware
update support for a big chunks of physical hardware being shitty (not
that shim updates look that much better right now ...)

My impression is that microsoft tries to improve the firmware security
situation without depending on firmware updates if possible.  Being more
strict on the PE binaries they are willing to sign for secure boot is
one step which goes into that category.

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

Yes.  Defining the key enrollment being job of the installer would work,
at least for the cases where an installation actually happens.

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

There is no standard for metadata though, along the lines of "when using
this disk image with secure boot you should use that uefi varstore".
What we have today is ec2-specific, you have to take care when creating
the AMI.

take care,
  Gerd



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