Saveoops: Making Kexec purgatory position-independent?

[Ahmed S. Darwish]

On Sat, Feb 26, 2011 at 04:57:30PM -0800, Eric W. Biederman wrote:
> "H. Peter Anvin" <hpa at zytor.com> writes:
> >
> > I can't see any sane reason to *not* make kexec purgatory
> > position-independent.  It is the obvious thing to do.
> 
> This isn't a case of the code not being position independent.  This is
> case of where the relocations are applied.
> 
> I can see a couple of handling this with different tradeoffs.
> 
> 1) We teach bootloaders how to load two kernels at once.  This
>    completely avoids the purgatory, as it is replaced by code in the
>    bootloader that already exists to load the primary kernel and setup
>    it's arguments.
> 

This is in fact my plan. Using Syslinux, I loaded 'purgatory.ro' to RAM
thinking that it will still be needed. Re-checking the purgatory code
now after reading above note, it seems it does 5 important points:

   a) reset the VGA (if instructed)
   b) reset the PIC to legacy mode (if instructed)
   c) check the overall integrity of the second kernel image (SHA-2)
   d) setup the environment for second kernel entry (switch back to
      32-bit protected mode in x86-64, reset registers, etc)
   e) saves the first 640K in a backup region

So (a) and (b) can be done elsewhere if needed; (c) isn't needed cause
if the bootloader corrupts images, we have bigger problems; (d) can be
done as a stub; (e), on the contrary of kdump, isn't critical for my
goals.

Am I missing an important detail?

> 2) We add minimal relocation processing to purgatory, allowing us to do
>    the setup for the second kernel extremely early and allow it to be
>    compiled into the first kernel.
> 
> 3) We come up with a scheme where we don't share code and the first
>    kernel copies the firmware information to place where the second
>    kernel can get at it, and uses it's own home grown stub and not
>    purgatory.
> 

Sorry, but how the third point differs from the first? I thought they
were complementary.

> I think this whole thing can be prototyped easily with a getting /sbin/kexec
> to load to a fixed address and then baking that section into the primary
> kernel. ...

I'll prototype this now by loading the second kernel (bzImage), using
syslinux, without the purgatory.  Let's hope I won't face many
surprises.

> ... I'm not convinced that directly using /sbin/kexec is the right
> way forward to handle the general case.  This is something where the
> devil is in the details.
> 

Lots of details per se; spent last week exploring Kexec user and
kernel code to understand how it does its magic.

> Eric

thanks,

-- 
Darwish
http://darwish.07.googlepages.com