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.
