Handling an elf kernel dump with a randomized base

[Corey Minyard]

On 02/09/2016 09:37 AM, Corey Minyard wrote:
> I have been working on getting kernels on different architectures with 
> randomized
> base operational.  One problem I've run into is that kernel dumps 
> taken this way are
> not debuggable with gdb, the symbols are, of course, all in the wrong 
> places.
>
> The way gdb handles relocation is to add an AT_ENTRY value in an auxv 
> note.  It holds
> the relocated start address and gdb uses that to figure out the 
> offsets.  This is
> easy enough to add if you have the information, I'm wondering the best 
> way to do
> this looking at getting it into the mainstream kernel and the crash 
> dump tools.
>
> There is some handling of this on x86_64 with KERNELOFFSET, but it 
> doesn't work for
> gdb.
>
> I can think of two ways to add this:
>
> * Add a vmcoreinfo value with the entry point and have the extraction 
> tool create
> the elf note.
>
> * Put the entry point in sysfs and have kexec add the note like it 
> does for
> vmcoreinfo.
>

I thought of a third possibility.  You could have a downstream tool that 
looks at the
value of a symbol (like _stext) in the vmcoreinfo and the vmlinux file 
and adds the
auxv note to the core dump.  That would require no changes to anything, but
would require the downstream tool.

-corey

> I'd like to avoid any solution that requires putting vmlinux or any 
> other large file
> on the target system, as this is not always possible for small 
> embedded systems.
>
> Thanks,
>
> -corey