Saveoops: Making Kexec purgatory position-independent?

[Simon Horman]

On Sat, Feb 26, 2011 at 04:57:30PM -0800, Eric W. Biederman wrote:
> "H. Peter Anvin" <hpa at zytor.com> writes:
> 
> > On 02/26/2011 08:20 AM, Ahmed S. Darwish wrote:
> >> Hi,
> >> 
> >> I'm continuing work on 'Saveoops', saving both early and normal Linux
> >> oops log to disk upon panic [*], using Kexec and bootloaders this time.
> >> 
> >> Purgatory, the transitional mini-kernel used by kexec, is a relocatable
> >> ELF file. Userspace kexec-tools finds the final load address of such
> >> code (by parsing /proc/iomem, etc) and then applies the relocations
> >> itself before passing the now-ready executable image to kernel.
> >> 
> >> Since capturing early oopses is the major goal, doing such relocation
> >> in userspace won't fit my purposes. Two options remain:
> >>    - relocate purgatory entries in the kernel early boot path
> >>    - or compile purgatory as position-independent, thus simplifying
> >>      the kernel load logic
> >> 
> >> The former will add extra logic in a sensitive path (early boot), while
> >> the latter will require changes inside the purgatory code itself,
> >> especially i386 assembly files.
> >> 
> >> Any preferable option from our kexec and x86 maintainers?
> >> 
> >> thanks!
> >> 
> >> [*] http://news.gmane.org/find-root.php?message_id=<20110125134748.GA10051@laptop>
> >>     http://news.gmane.org/find-root.php?message_id=<20110126124954.GC24527@laptop>
> >> 
> >
> > 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.

I can think of plenty of scenarios where that isn't entirely useful.
For example using kexec as a boot loader and as such not necessarily having
any idea what the second kernel will look like at the time that the first
kernel is built. Am I missing something?

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