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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 16/06/2026 11:06 am, Ross Lagerwall wrote:
> 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


By "real mode setup", for the purposes here that's the PE+/bzImage64
polygot header?

Where does the (hypercall) segment start point?  Surely at the start of
the PE+/bzImage64 header?

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


What is necessary is that the segment dest_maddr is chosen such that the
start of the embedded kernel has correct alignment in the eventual
identity map.  This property is either true or it's not, and there
shouldn't be a round() calculation required to generate the entrypoint.


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

Yes, that's where we're going, but the constraints need understanding first.

The old load types had nothing really architecture specific in it.  It
was a bunch of bytes, and an arbitrary point to jump to.

With this new "EFI" load type, we've got structural information.  We
don't need userspace to pass in a starting point because we can locate
it ourselves.

We do want to restrict it to a valid PE+(x86_64)/bzImage64 polygot, and
this will require arch specific functions to decide whether we like the
image, and to figure out the entrypoint.

~Andrew