Re: [PATCH 0/2] xen/efi: Make boot more flexible, especially with GRUB2

[Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

On Tue, Jul 01, 2025 at 03:31:19PM +0100, Frediano Ziglio wrote:
> On Fri, Jun 27, 2025 at 5:20 PM Marek Marczykowski-Górecki
> <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Fri, Jun 27, 2025 at 04:58:43PM +0100, Frediano Ziglio wrote:
> > > On Fri, Jun 27, 2025 at 3:20 PM Marek Marczykowski-Górecki
> > > <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> > > > So, it looks like major distributions use a patched grub version that
> > > > changes behavior of "linux" command. IIUC many of those patches are
> > > > about hardening SecureBoot, and shim-review kinda suggest using patched
> > > > version (many of the submissions explicitly mention the at least patch
> > > > grub for NX). So, I think this needs figuring out how to make your
> > > > approach working with grub flavor that is actually used by SB-enabled
> > > > distributions...
> > > >
> > >
> > > We (xenserver) would like to provide booting using separate
> > > hypervisor, kernel and initrd.
> > > Using "linux" was an old discussed option which had a nice usage.
> > > The merged patches allow to have a fully UKI file bundling kernel and
> > > initrd loaded from no-ESP partition which is nice to have.
> > > For the final solution I was thinking about using "xen_hypervisor" and
> > > "xen_module" already present for ARM. From the user perspective is
> > > surely less confusing than using "linux" to pass something which is
> > > not Linux.
> >
> > In which case, loading initrd using Linux-specific grub part doesn't
> > make sense, no? Or is that xen_module going to use similar mechanism?
> >
> 
> Yes, the idea is to reuse this mechanism instead of reinventing the wheel.
> 
> You can see the problem from 2 perspectives:
> - User usage;
> - Boot protocol.
> 
> From the user usage the user (possibly human, but at least the
> configuration should be user understandable) the usage of "linux" to
> load something which is not Linux is confusing although in the past
> the "kernel" command was abused to load lot of things, and a lot of
> things presented themselves as Linux kernels to be loaded by different
> boot loaders (even Syslinux had this habits).
> 
> From the boot protocol perspective. A boot loader loads some binaries
> and uses some boot protocol to pass the control and different
> information to the "next" binary. Information can include
> - command line
> - modules
> - memory information
> - video information
> - ...
> EFI supports by itself memory and video information, can carry a
> string (so the command line) but lacks module information. Here came
> all a set of way to pass modules, specifically:
> - multiboot 1 and 2
> - GRUB LoadFile2
> - device tree (ARM)
> Multiboot does not work very well with PE (the protocol is designed
> for ELF or binary/raw loading) so we are trying to move away from it.
> Device tree (used by xen_hypervisor and xen_module GRUB commands) is
> ARM specific.
> What is left (without adding a new method) is LoadFile2. So we are
> using this way to pass additional modules. Just added a new media GUID
> to pass also the kernel, not only initrd (at the moment the GRUB
> changes are very hacky but the protocol is the same).

Ok, so the plan is to use GRUB LoadFile2 as a mechanism to load initrd
(and maybe kernel too?) for EFI boot on x86. This in itself sounds fine
for me.
The part that is worrying for me is interaction of the context in which
this is introduced, with various downstream GRUB forks (IMO a
"distribution package" that applies 200+ patches should be called this
way, it isn't just a "package" anymore). A large part of those patches,
both in Fedora and in Debian is related to SecureBoot support. Using
patched GRUB is also kinda recommended as part of getting Microsoft to
sign the shim package (the shim-review process). Now, if the LoadFile2
approach is introduced as part of making Xen SecureBoot-ready, but it
does not work with a GRUB version that is supposed to be used with
SecureBoot I see a problem. I'm not sure exactly where the issue is
(could be something about how our xen.efi looks like, but could be also
a downstream GRUB issue), but IMO it's worth at least figuring out where
the issue is (and whether it's just a bug, or some intentional
behavior - possibly to comply with some SB requirements). To avoid
situation where the version that is made to be SecureBoot-ready won't
actually be bootable by any SecureBoot-ready bootloader...

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

Attachment: signature.asc
Description: PGP signature