<div dir="ltr">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.<div><br></div><div>I'm busy with something else right now, and I'll be able to get back to this in 1-2 weeks.</div>
<div><br></div><div>thanks,</div><div>Andy</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 22, 2014 at 3:28 PM, Kees Cook <span dir="ltr"><<a href="mailto:keescook@google.com" target="_blank">keescook@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, Jan 22, 2014 at 12:32 PM, Dave Anderson <<a href="mailto:anderson@redhat.com">anderson@redhat.com</a>> wrote:<br>

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