Saveoops: Making Kexec purgatory position-independent?

[Vivek Goyal]

On Sun, Feb 27, 2011 at 03:24:09PM +0200, Ahmed S. Darwish wrote:
> 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;

First kernel boot itself could corrupt the second kernel?

Secondly, Once you are booted sucessfully, I guess same can be used for
regular kernel crash without reloading the kdump kernel (For poeple who are
looking to capture just logs). If yes, it will be good to check integrity
of second kernel image.

Is bootloader going to set up the kernels in such a way that second kernel
boot is not going to overwrite the first kernel's memory? Otherwise how
do we make sure that second kernel does not overwrite the oops/logs
information you are trying to save.

On a side note, does UEFI provide some functionality where first kernel
can save some limited amount of buffer and retrieve it back when a new
kernel is booting. I might be completely into weedes here. This is just
based on discussion with somebody long back who mentioned that UEFI
might allow us to save kernel oops and the retrieve it back when fresh
kernel is booting.

Do two kernels boot from mutually exclusive locations or you will continue
to copy new kernel at some low meory address and boot from there? Copying
will again lead to issue of how not to overwrite or concept of backup
region. For not copying we need to make sure what the highest address
kernel can boot from and also letting first kernel know not to overwrite
second kernel.

Above are just some random thoughts without going into details of the proposal.

Thanks
Vivek
 

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