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