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

[Jinpu Wang]

On Tue, Jun 5, 2018 at 3:02 PM, Dave Anderson <anderson at redhat.com> wrote:
>
>
> ----- 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
Thank you Dave for detailed explanation, I must misread the man page
regarding mapfile usage.
It's clear now.

Regards,
Jack Wang