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