On Wed, 2005-02-02 at 21:12, Eric W. Biederman wrote: > Vivek Goyal <[EMAIL PROTECTED]> writes: > > > On Tue, 2005-02-01 at 20:56, Eric W. Biederman wrote: > > > Vivek Goyal <[EMAIL PROTECTED]> 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.
Sounds good. So there shall be a PT_NOTE type program header per cpu. And these headers can be collapsed into one PT_NOTE type header later. > > > > 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 > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
