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

On Wed, Jan 22, 2014 at 12:32 PM, Dave Anderson <anderson(a)redhat.com&gt; wrote: > > > ----- Original Message ----- >> On Wed, Jan 22, 2014 at 10:42 AM, Dave Anderson <anderson(a)redhat.com&gt; 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