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 at laptop> > >> http://news.gmane.org/find-root.php?message_id=<20110126124954.GC24527 at 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 >
