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

[Frediano Ziglio <frediano.ziglio@xxxxxxxxx>]

On Fri, Jun 27, 2025 at 3:20 PM Marek Marczykowski-Górecki
<marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Fri, Jun 27, 2025 at 01:29:48PM +0100, Frediano Ziglio wrote:
> > On Thu, Jun 26, 2025 at 4:03 PM Marek Marczykowski-Górecki
> > <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > On Thu, Jun 26, 2025 at 09:12:53AM +0100, Frediano Ziglio wrote:
> > > > On Wed, Jun 25, 2025 at 9:26 PM Marek Marczykowski-Górecki
> > > > <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> > > > >
> > > > > On Tue, Jun 24, 2025 at 09:38:42AM +0100, Frediano Ziglio wrote:
> > > > > > On Tue, Jun 24, 2025 at 9:32 AM Frediano Ziglio
> > > > > > <frediano.ziglio@xxxxxxxxx> wrote:
> > > > > > >
> > > > > > > The combination of GRUB2, EFI and UKI allows potentially more 
> > > > > > > flexibility.
> > > > > > > For instance is possible to load xen.efi from a no ESP partition 
> > > > > > > leaving
> > > > > > > a boot loader like GRUB2 taking care of the file loading.
> > > > > > > This however requires some changes in Xen to be less restrictive.
> > > > > > > Specifically for GRUB2 these changes allows the usage of 
> > > > > > > "chainloader"
> > > > > > > command with UKI and reading xen.efi from no ESP (so no 
> > > > > > > DeviceHandle
> > > > > > > set) and usage of "linux" and "initrd" commands to load separately
> > > > > > > the kernel (embedding using UKI) and initrd (using LoadFile2 
> > > > > > > protocol).
> > > > > >
> > > > > > I was forgetting. If somebody wants to test "linux" and "initrd"
> > > > > > command with these changes be aware that GRUB currently has a 
> > > > > > problem
> > > > > > passing arguments, I posted a patch, see
> > > > > > https://lists.gnu.org/archive/html/grub-devel/2025-06/msg00156.html.
> > > > > > I also have a workaround for this issue in xen but it would be 
> > > > > > better
> > > > > > to have a fix in GRUB.
> > > > >
> > > > > Can you tell more how to test this, especially the second variant? 
> > > > > When
> > > > > trying to use GRUB linux or linuxefi commands on xen.efi, I get 
> > > > > "invalid
> > > > > magic number" error.
> > > > >
> > > >
> > > > That's weird.
> > > >
> > > > Be the way. As usual I have a super complicated script that does 
> > > > everything.
> > > >
> > > > But to simplify:
> > > > - I compile xen (plain upstream plus my patches) with "make -C
> > > > ~/work/xen/xen -j O=normal MAP"
> > >
> > > Is there any that would be related to the "invalid magic" error? IIUC
> > > without your patches options will be mangled, but I don't think I get
> > > this far.
> > >
> >
> > I tried to do some changes and check the CI with your branch. Not hard
> > to reproduce and the test looks correct.
> > Looking at GRUB code I can see various "linux" command implementations
> > and it looks like yours is picking up i386-pc target and not
> > x86_64-efi one which is really odd to me.
>
> Indeed, very odd, I do pass -O x86_64-efi option explicitly...
>
> But also, when I do the test locally with grub 2.12 from Fedora, I get the 
> filename
> prefix:
>
>     error: ../../grub-core/loader/i386/efi/linux.c:387:invalid magic number.
>
> which does look like the efi variant.
>
> This is even more interesting, as this path does not exist in the
> upstream repository. It appears as it's _yet another_ linux loader added
> by Fedora package:
> https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/0213-Add-support-for-Linux-EFI-stub-loading.patch
> That code I think looks for some Linux-specific header with "EFI
> handover" pointer?
>

So, yet another "linux" loader :-(
I found that a bit crazy... Why not have a single "linux"
implementation calling different architecture specific functions? I
mean, some parts like arguments parsing and handling are pretty
common, the syntax should be the same. And is not the Linux booting
format already complicated enough to add another entry point format?

> I don't see exactly this patch in Debian package, but there are also
> some messing with the 'linux' command, so I guess it may be similar
> issue.
>
> If I use upstream grub directly, then the "linux" command indeed doesn't
> complain.
>
> 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.

Frediano