[Crash-utility] regression with System.map handling on 4.14 +?

[Dave Anderson]

----- Original Message -----
> Hi Dave, hi co,
> 
> I noticed a behaviour change regarding System.map handling regarding
> newer kernel like 4.14+
> 
> As a example:
> below command works:
> crash -d 1 vmlinux-4.14.43-1-pserver ps402a-30-dump.201806041421 > good.txt
> 
> below command report error:
> crash -d 1 vmlinux-4.14.43-1-pserver System.map-4.14.43-1-pserver
> ps402a-30-dump.201806041421 > bad.txt
> 
> crash: page excluded: kernel virtual address: ffffffff82237f18  type:
> "page_offset_base"
> 
> When compare the difference between good.txt and bad.txt, I noticed
> following only in good.txt:
> KASLR:
>   _stext from vmlinux-4.14.43-1-pserver: ffffffff81000000
>   _stext from vmcoreinfo: ffffffff9e000000
>   relocate: 1d000000 (464MB)
> 
> I tried also on latest Ubuntu 1804, crash reports same error when run
> with System.map file.
> 
> Is this expected?

First question: why are you using the System.map file as a command line argument?

It only make sense to do so if vmlinux-4.14.43-1-pserver is *not* the kernel that
was running when ps402a-30-dump.201806041421 was generated.  Are you rebuilding a
similarly-configured kernel in order to try to create something "close" to the kernel
that crashed?  If that's true, then that is the only reason to use the System.map
file of the kernel that crashed.  However...

Secondly: it appears that your kernel is running with KASLR enabled and the
kernel static text/data has been relocated -- where the the debug message shows
that _stext has been relocated from ffffffff810000 to ffffffff9e000000.  In that
case, the crash utility will perform the gdb back-patching of all kernel symbols 
using the relocation value of 1d000000.  However, if you apply the System.map
file as a command line argument, it sets the symbol values back to the addresses
in the System.map file, which are the original non-relocated addresses compiled
into the vmlinux file.

So the short answer is -- NEVER use the System.map file unless you cannot
access the original vmlinux file and you are trying to simulate it by rebuilding
a similarly-configured kernel.  But if that is done, KASLR complicates things
because the System.map file contains the non-relocated symbol values that were
compiled into the vmlinux file.  In that case, then I suppose you would have to
create a System.map-like file *before* the kernel crashed by copying /proc/kallsyms to
a "fake" System.map file.  Since the relocation value changes with each boot,
it's too late after the crash, and so in that case I don't have any suggestions.

Just keep in mind that using a System.map file is somewhat of a desperate override,
telling the crash utility to just use the symbol values within it.  
 
Dave
  



> 
> Thanks,
> --
> Jack Wangv 
> Linux Kernel Developer
> 
> ProfitBricks GmbH
> Greifswalder Str. 207
> D - 10405 Berlin
> 
> Tel:       +49 30 577 008  042
> Fax:      +49 30 577 008 299
> Email:    jinpu.wang at profitbricks.com
> URL:      https://www.profitbricks.de
> 
> Sitz der Gesellschaft: Berlin
> Registergericht: Amtsgericht Charlottenburg, HRB 125506 B
> Geschäftsführer: Achim Weiss, Matthias Steinberg, Christoph Steffens
>