Re: [PATCH 5/7] x86/kexec: Implement new EFI load types

[Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>]

On 6/15/26 8:34 PM, Kevin Lampis wrote:
>  >Ok, so here is startup_64, hidden as a magic constant.
>  >... you're applying the alignment to the pointer and picking
>  >startup_64 out of thin air.
>
> I'm going to be cheeky and play the Linux-does-it-too card.
> https://github.com/torvalds/linux/blob/master/arch/x86/kernel/kexec-bzimage64.c#L660
>
>  >Either it was loaded correctly (and the alignment is correct), or it was
>  >loaded incorrectly and this is unsafe to do, is it not?
>
> This is what the kernel kexec segment looks like in memory
>
>                                            .- dest_maddr + alignment
>     .-dest_maddr                           |
>     v                                      v
>     +--------------------------------------+--------------------...
>     | padding            | real-mode setup | kernel
>     +--------------------------------------+--------------------...
> 0x000000                               0x200000
>
> In the old non-EFI kexec the 16-bit real-mode setup portion is
> chopped off by the userspace tools and the segment buffer that Xen
> receives is just the "kernel" part. But we need to pass both the
> real-mode setup + kernel to kexec_load to pass Secure Boot
> verification. And add padding so it straddles a 2M boundary like this.
>
> What the 0x200000 "alignment" variable is doing is skipping over the
> real-mode setup and padding.
>
> It won't necessarily be 0x200000 though which is why we need to read
> the value from Linux's setup_header->kernel_alignment.
>
> If you're hinting that perhaps userspace should take care of all this
> and just tell Xen where startup_64 is then perhaps. That would be a
> bigger change we need to get input from Ross on though.
It was done in Xen because there was a concern that letting userspace
pass in an arbitrary start address would potentially allow a Secure Boot
bypass even if it restricted within the bounds of the kernel image.

The patch should probably make it clear that this load type _only_ works
for Linux bzImages using the x86 64-bit boot protocol documented at
linux/Documentation/arch/x86/boot.rst. I think it needs sanity checks as
well to ensure that it has actually been given an x86 bzImage and that
the boot protocol version number is as expected.

Since it is x86 specific, maybe it wants to move out of common code?

Ross