Re: x86_64 32-bit EFI mixed mode boot broken

[Ard Biesheuvel]

On Fri, 22 Mar 2024 at 18:19, Clayton Craft <clayton@xxxxxxxxxxxxx> wrote:
>
> On Fri, 22 Mar 2024 13:52:05 +0100 Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
> > That depends on the bootloader. One of the changes around that time is
> > the introduction of this Kconfig symbol: before that, the EFI handover
> > protocol was always supported but now it can be compiled out. So the
> > safe choice is to enable it.
>
> I am using systemd-boot, and based on my understanding of its source it seems to
> only use handover on old kernels that don't support LINUX_INITRD_MEDIA_GUID.

That does ring a bell. So that means you must be using the .compat
entry point, which is what 32-bit OVMF uses too.

> >
> > However, while looking more deeply into this, I noticed that we are
> > running quite low own stack space. Mixed mode is different because it
> > calls into the boot services using the decompressor's boot stack,
> > rather than using the one that was provided by firmware at entry.
> > (Note that the UEFI spec mandates 128k of stack space)
> >
> > In my case, I bisected the regression to
> >
> > commit 5c4feadb0011983bbc4587bc61056c7b379d9969 (HEAD)
> > Author: Ard Biesheuvel <ardb@xxxxxxxxxx>
> > Date:   Mon Aug 7 18:27:16 2023 +0200
> >
> >     x86/decompressor: Move global symbol references to C code
> >
> > which moves the boot stack into a different memory region. Formerly,
> > we'd end up at the far end of the heap when overrunning the stack but
> > now, we end up crashing. Of course, overwriting the heap can cause
> > problems of its own, so we'll need to bump this in any case.
> >
> > Could you give this a try please?
> >
> >
> > --- a/arch/x86/include/asm/boot.h
> > +++ b/arch/x86/include/asm/boot.h
> > @@ -38,7 +38,7 @@
> >  #endif
> >
> >  #ifdef CONFIG_X86_64
> > -# define BOOT_STACK_SIZE       0x4000
> > +# define BOOT_STACK_SIZE       0x10000
> >
> >  /*
> >   * Used by decompressor's startup_32() to allocate page tables for identity
>
> Just gave this a try, on 6.1.82, and the system still reboots after selecting
> the kernel in the bootloader. So it seems like my problem is different.
>

Yeah, it was a long shot.

> As I mentioned initially, I bisected my failure to e2ab9eab32. Does that give
> any hint about what might be the problem?
>

Not at all, unfortunately. What we might try is to back out the
changes step by step. I can prepare a branch for you if you like.