Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.

[ebiederm@xmission.com (Eric W. Biederman)]

Vivek Goyal <vgoyal@in.ibm.com> writes:

> On Tue, 2005-02-01 at 20:56, Eric W. Biederman wrote:
> > Vivek Goyal <vgoyal@in.ibm.com> writes:
> 
> "elfcorehdr=" also looks good.

Then let's go with that for now.  It is not perfect but it seems
a little more self explanatory at first glance.

> > A clarification on terminology we are talking about struct Elf64_Phdr
> > here.  There is only one Elf header.  That seems to be clear farther
> > down.
> > 
> 
> 
> Exactly. There shall be one Elf header for whole of the image. In
> addition there will be one struct Elf64_Phdr, per contiguous physical
> memory area. One Elf64_Phdr of PT_NOTE type for notes section and one
> Elf64_Phdr for backup region.

Actually if we are just pointing a kernel data structures we will
need multiple Elf64_Phdr of PT_NOTE.  Each cpu has it's own
notes section and until the smoke clears we can't be confident
about what is going to wind up there or how densely those will
be packed.  So collapsing everything into a single notes segment
needs to happen after we have switched to the crash capture kernel.

> > I have serious concerns about the kernel generating the ELF headers
> > and only delivering them after the kernel has crashed.  Because
> > then we run into questions of what information can be trusted.  If we
> > avoid that issue I am not too concerned.
> 
> 
> I hope, all elf headers once prepared by kexec-tools need not to change
> later (Cannot think of any piece of information which shall change
> later). These shall be put in separate segment. And SHA-256 shall take
> care of authenticity of information after crash.

That should work fine.  We need to consider through throwing in an
extra note section with information like kernel version that
we can capture while the system is running.

> For notes section program header, virtual = physical = 0 and "offset"
> shall point to crash_notes[], so that notes can directly be read by the
> capture kernel (or user space).

I agree.  But see my caveat.  I think we should have one PT_NOTE
segment point at each element of the crash_notes[] array.  I know
it is technically a violation of the ELF spec.  But in this case
it makes sense.   Since we can't guarantee that crash_notes will
be packed properly I don't know that we could reliably see more
than one cpu if we pointed a PT_NOTE header at the whole thing.

If it turns out that we can reliably point a single PT_NOTE header
at crash_notes so much the better but things are likely to be
more robust if we don't start with that assumption.  That
at least allows us the freedom to capture some notes (like NT_UTSNAME)
before the kernel crashes.

Eric