On Tue, Feb 18, 2014 at 12:27 PM, Dave Anderson <anderson@xxxxxxxxxx> 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
