[Crash-utility] earlier patch introducing the --kaslr option

[Kees Cook]

On Tue, Feb 18, 2014 at 12:27 PM, Dave Anderson <anderson at redhat.com> wrote:
>
>
> ----- Original Message -----
>> >
>> > But if I try that value with your patch applied, it fails in the same manner
>> > as if I don't use the --kaslr option at all:
>> >
>> >  $ crash --kaslr 0x19000000 vmlinux vmcore
>> >
>> >  crash 7.0.5rc12
>> >  Copyright (C) 2002-2014  Red Hat, Inc.
>> >  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
>> >  Copyright (C) 1999-2006  Hewlett-Packard Co
>> >  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
>> >  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
>> >  Copyright (C) 2005, 2011  NEC Corporation
>> >  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
>> >  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
>> >  This program is free software, covered by the GNU General Public License,
>> >  and you are welcome to change it and/or distribute copies of it under
>> >  certain conditions.  Enter "help copying" to see the conditions.
>> >  This program has absolutely no warranty.  Enter "help warranty" for
>> >  details.
>> >
>> >  GNU gdb (GDB) 7.6
>> >  Copyright (C) 2013 Free Software Foundation, Inc.
>> >  License GPLv3+: GNU GPL version 3 or later
>> >  <http://gnu.org/licenses/gpl.html>
>> >  This is free software: you are free to change and redistribute it.
>> >  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> >  and "show warranty" for details.
>> >  This GDB was configured as "x86_64-unknown-linux-gnu"...
>> >
>> >  WARNING: could not find MAGIC_START!
>> >  WARNING: cannot read linux_banner string
>> >  crash: vmlinux and vmcore do not match!
>> >
>> >  Usage:
>> >
>> >   crash [OPTION]... NAMELIST MEMORY-IMAGE  (dumpfile form)
>> >   crash [OPTION]... [NAMELIST]             (live system form)
>> >
>> >  Enter "crash -h" for details.
>> >  $
>> >
>> > Any ideas?  I can give you the vmlinux/vmcore/kallsyms triplet if you'd
>> > like.
>>
>> As far as why the offset wasn't present, sorry about that.  I guess
>> our tool chain is a bit more different than upstream, I've had a bit
>> of trouble generating kdump files for upstream.
>>
>> Your manual calculations look correct to me though and it should work.
>>  If you can send me the vmlinux/vmcore triplet (I don't think I need
>> the kallsyms) then I will look at this today.  Can you post it
>> somewhere I can download it?
>>
>> Sorry for the delay I was on vacation.
>>
>> thanks,
>> Andy
>
> Actually you do need the kallsyms...
>
> As I mentioned to Kees in an earlier message, the display of
> the offset in the kernel log will not be done in the case of
> kdump-enabled kernels, because crash_kexec() is called before
> the panic_notifier list is executed, and crash_kexec() does
> not return.
>
> I've put the triplet here:
>
>   http://people.redhat.com/anderson/kaslr
>
> Note that we can only create ELF vmcores with kASLR because the makedumpfile
> facility also needs to be fixed to handle kASLR kernels.
>
> Anyway, as it turns out, the offset is not 0x19000000 (&_text - __START_KERNEL),
> but rather it is 0x18000000, which is the difference between the
> kallsyms symbol values and those compiled into the vmlinux file.
> With that --kaslr offset value, the crash session comes up OK.

Oh, hm. Is the difference maybe due to CONFIG_PHYSICAL_START some how?

-Kees

> So it seems that the (incorrect) advertised offset may not be needed,
> because you can take any of the symbol values exported in the vmcoreinfo data
> and compare them to their symbol value from the vmlinux file.  For live systems,
> the same sort of thing could be done by comparing the vmlinux symbols to the
> /proc/kallsyms values.  But we still should have a command line option like
> your original patch as a "back-up".
>
> Thanks,
>   Dave
>
>
>
>
>
>
>



-- 
Kees Cook
Chrome OS Security