Received-SPF: pass (google.com: domain of linux-kernel+bounces-111807-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240321150510.GI8211@craftyguy.net> <CAMj1kXGzH4TiwvSF3bZsJpuuWf04Ri_852fUMTdH8pLRaH3+Yg@mail.gmail.com>
 <20240321170641.GK8211@craftyguy.net> <CAMj1kXE-sxGM2H8akunJ1mZPDSVX1+2ehDtK-jqW--8tw9J5LA@mail.gmail.com>
 <20240322091857.GM8211@craftyguy.net>
In-Reply-To: <20240322091857.GM8211@craftyguy.net>
From: Ard Biesheuvel <ardb@kernel.org>
Date: Fri, 22 Mar 2024 18:51:46 +0200
Message-ID: <CAMj1kXFmnv+FGRMnnJMJejj5yvSybgZTNEYZz0hxb6K9VAeo1Q@mail.gmail.com>
Subject: Re: x86_64 32-bit EFI mixed mode boot broken
To: Clayton Craft <clayton@craftyguy.net>
Cc: Hans de Goede <hdegoede@redhat.com>, x86@kernel.org, linux-kernel@vger.kernel.org, 
	linux-efi@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, regressions@lists.linux.dev
Content-Type: text/plain; charset="UTF-8"

On Fri, 22 Mar 2024 at 18:19, Clayton Craft <clayton@craftyguy.net> wrote:
>
> On Fri, 22 Mar 2024 13:52:05 +0100 Ard Biesheuvel <ardb@kernel.org> 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@kernel.org>
> > 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.