Saveoops: Making Kexec purgatory position-independent?
horms at verge.net.au
Sun Feb 27 20:38:29 EST 2011
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
> 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.
More information about the kexec