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

["Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>]

[-- Attachment #1: Type: text/plain, Size: 3982 bytes --]

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@invisiblethingslab.com> 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@invisiblethingslab.com> 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@cloud.com> 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?

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]