[Crash-utility] [PATCH v3] Add support for kASLR for offline vmcore files

[Andrew Honig]

Sorry for the slow response.  I haven't completely moved on and I'd like to
put together another patch that uses data from the vmcore_info.

I'm busy with something else right now, and I'll be able to get back to
this in 1-2 weeks.

thanks,
Andy


On Wed, Jan 22, 2014 at 3:28 PM, Kees Cook <keescook at google.com> wrote:

> On Wed, Jan 22, 2014 at 12:32 PM, Dave Anderson <anderson at redhat.com>
> wrote:
> >
> >
> > ----- Original Message -----
> >> On Wed, Jan 22, 2014 at 10:42 AM, Dave Anderson <anderson at redhat.com>
> wrote:
> >> >
> >> >
> >> > ----- Original Message -----
> >> >> >> >
> >> >> >> > Then, my questions are:
> >> >> >> >
> >> >> >> >  (1) on a live system, how would a root user determine the
> offset
> >> >> >> >  from userspace?
> >> >> >>
> >> >> >> AFAICT, it can be calculated from /proc/kallsyms.
> >> >> >
> >> >> > Will /proc/kallsyms contain the relocated addresses?  Andy had
> mentioned
> >> >> > that
> >> >> > the offset would be in the dmesg buffer but that can be
> overwritten.
> >> >>
> >> >> Yeah, kallsyms should show the current actual locations. It should
> >> >> only show up in dmesg on a crash.
> >> >>
> >> >> >> >  (2) given a random vmlinux/vmcore pair, how would any user
> determine
> >> >> >> >  the offset?
> >> >> >>
> >> >> >> It'd be nice for the vmcore to contain offset details.
> >> >> >
> >> >> > Right -- Andy mentioned that it would be put in a VMCOREINFO item:
> >> >> >
> >> >> >
> https://www.redhat.com/archives/crash-utility/2013-October/msg00043.html
> >> >> >
> >> >> > But I'm presuming that wasn't part of your patchset.
> >> >>
> >> >> It was not, no. What's needed to get that added?
> >> >
> >> > Since kASLR is x86 only (right?), I believe it would simply require an
> >> > addition to "arch/x86/kernel/machine_kexec_64.c" here:
> >> >
> >> > void arch_crash_save_vmcoreinfo(void)
> >> > {
> >> >         VMCOREINFO_SYMBOL(phys_base);
> >> >         VMCOREINFO_SYMBOL(init_level4_pgt);
> >> >
> >> > #ifdef CONFIG_NUMA
> >> >         VMCOREINFO_SYMBOL(node_data);
> >> >         VMCOREINFO_LENGTH(node_data, MAX_NUMNODES);
> >> > #endif
> >> > }
> >> >
> >> > Since it's the offset value that we're interested in, something
> >> > like this should suffice:
> >> >
> >> >         VMCOREINFO_NUMBER(<name_of_symbol_containing_offset_value>)
> >> >
> >> > with an appropriate header inclusion that declares the symbol,
> >> > and enclosed by whatever "CONFIG_<kASLR>" you've got in place.
> >> >
> >> > The macro looks like this:
> >> >
> >> > #define VMCOREINFO_NUMBER(name) \
> >> >         vmcoreinfo_append_str("NUMBER(%s)=%ld\n", #name, (long)name)
> >> >
> >> > Of course that presumes you've got a symbol in place that holds the
> offset?
> >> >
> >> > On a related note, the VMCOREINFO_SYMBOL(phys_base) above is
> completely
> >> > useless, and should also have been introduced as
> >> > VMCOREINFO_NUMBER(phys_base).
> >> > The makedumpfile maintainers on this list can confirm it, but I
> >> > don't believe that they use it either, but just pass it on to the
> >> > crash utility to ignore.  Both the crash utility and makedumpfile
> >> > jump through hoops to figure out the phys_base value when it could
> >> > simply be passed in the vmcoreinfo data.
> >>
> >> FWIW, the offset reported during a panic to dmesg is:
> >>     (unsigned long)&_text - __START_KERNEL
> >>
> >> I think this is what Andrew was looking at for pushing into the vmcore
> info.
> >>
> >> -Kees
> >
> > OK good.  Since VMCOREINFO_NUMBER() won't work without a variable, maybe
> Andrew
> > was planning to create something like a new VMCOREINFO_KASLR_OFFSET() in
> > include/linux/kexec.h?  BTW, is he still going to work on this or has he
> moved
> > on to other things?
>
> I'll let him correct me, but I think he's still working on this area,
> but is presently busy with other stuff. I'll email the patch...
>
> -Kees
>
> --
> Kees Cook
> Chrome OS Security
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20140123/b77ceaf6/attachment.htm>