[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 08 Oct 2013 18:52:36 +0900
From: HATAYAMA Daisuke <d.hatayama@...fujitsu.com>
To: Dave Anderson <anderson@...hat.com>
CC: Kees Cook <keescook@...omium.org>,
LKML <linux-kernel@...r.kernel.org>,
x86@...nel.org, kernel-hardening@...ts.openwall.com,
Aaron Durbin <adurbin@...gle.com>,
Eric Northup <digitaleric@...gle.com>, Julien Tinnes <jln@...gle.com>,
Will Drewry <wad@...gle.com>,
Mathias Krause <minipli@...glemail.com>,
Zhang Yanfei <zhangyanfei@...fujitsu.com>,
"H. Peter Anvin" <hpa@...or.com>,
"Discussion list for crash utility usage, maintenance and development" <crash-utility@...hat.com>
Subject: Re: [PATCH 6/7] x86, kaslr: report kernel offset on panic
(2013/10/07 22:21), Dave Anderson wrote:
> ----- Original Message -----
>> (2013/10/03 22:47), Dave Anderson wrote:
>>> ----- Original Message -----
>>>> (2013/10/02 18:13), HATAYAMA Daisuke wrote:
>>>>> (2013/10/02 16:48), Kees Cook wrote:
>>
>> Thanks for detailed explanation. So, there's already a feature in crash utility
>> to address relocation!, though it's better for me to try them to check if it's
>> really applicable to this feature. My concern is whether --reloc works well
>> on x86_64 too, because relocation has never done on x86_64 ever, right?
>
> Correct.
>
>> Another concern is that in case of relocation, users need to additional information
>> regarding runtime symbol information to crash utility. I want to avoid additional
>> process, automation is preferable if possible.
>
> Right. As I mentioned in the case of 32-bit x86 dumpfiles, there is no automation
> available when CONFIG_PHYSICAL_START is larger than CONFIG_PHYSICAL_ALIGN. The user
> either has to be aware of their values in order to calculate the --reloc argument,
> or has to capture a copy of the /proc/kallsyms file on the crashed system. Typically
> users/distros using kdump changed their x86 configurations to avoid having to deal
> with that.
>
Sorry, I don't understand why relocation size cannot be calculated when
CONFIG_PHYSICALSTART > CONFIG_PHYSICAL_ALIGN. Could you explain that?
>> I guess it's enough if there's runtime symbol addresses because we can get relocated
>> offset value by comparing it with the compile-time symbol address contained in
>> a given debuginfo file. Candidates for such symbols are the ones contained in
>> VMCOREINFO note containing some symbol values for makedumpfile to refer to mm-related
>> objects in kernel, which is always contained in vmcore generated by current kdump and
>> also vmcores converted by makedumpfile from it. How about this idea?
>
> But how would that differ from using an incorrect (non-matching) vmlinux file?
>
It seems to me almost similar to what crash currently does even if we do relocation check.
The current check crash currently does is trial-and-error since there's no information
indicating given vmcore and vmlinuxcertainly match well.
For example, the process I imagine is:
1) try to match vmcore and vmlinux with no relocation. If fails, go to 2).
2) try to match vmcore and vmlinux with relocation.
The two steps include symbol table initialization so it might actually be difficult to
resume back from 2) to 1).
Also, if gap due to phys_base and gap due to relocation can happen at the same time,
calculating two values automatically might be futher complicated. So, it would be better
to add relocation value in VMCOREINFO. Then, what crash utility sholud do becomes very simple.
BTW, can it really happen that gaps due to phys_base and due to relocation happen at the
same time? I feel relocation covers phys_base mechanism. If there's relocation, phys_base
is not necessary.
--
Thanks.
HATAYAMA, Daisuke
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
