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

[Frediano Ziglio <frediano.ziglio@xxxxxxxxx>]

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

Frediano