* Kees Cook <keescook(a)chromium.org&gt; wrote: > From: Eugene Surovegin <surovegin(a)google.com&gt; > > Include kASLR offset in VMCOREINFO ELF notes to assist in debugging. > > Signed-off-by: Eugene Surovegin <surovegin(a)google.com&gt; > Signed-off-by: Kees Cook <keescook(a)chromium.org&gt; > --- > v2: > - make sure "From:" got sent correctly > --- > arch/x86/kernel/machine_kexec_64.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c > index 4eabc160696f..679cef0791cd 100644 > --- a/arch/x86/kernel/machine_kexec_64.c > +++ b/arch/x86/kernel/machine_kexec_64.c > @@ -279,5 +279,7 @@ void arch_crash_save_vmcoreinfo(void) > VMCOREINFO_SYMBOL(node_data); > VMCOREINFO_LENGTH(node_data, MAX_NUMNODES); > #endif > + vmcoreinfo_append_str("KERNELOFFSET=%lx\n", > + (unsigned long)&_text - __START_KERNEL); > } I've Cc:-ed Adrian Hunter, who has sent the following kaslr fixes for perf yesterday: http://lkml.org/lkml/2014/1/24/220 Adrian, is this patch the right solution from the perf tooling perspective?

Thanks, Ingo

* Adrian Hunter <adrian.hunter(a)intel.com&gt; wrote: > On 25/01/14 09:47, Ingo Molnar wrote: >> >> * Kees Cook <keescook(a)chromium.org&gt; wrote: >> >>> From: Eugene Surovegin <surovegin(a)google.com&gt; >>> >>> Include kASLR offset in VMCOREINFO ELF notes to assist in debugging. >>> >>> Signed-off-by: Eugene Surovegin <surovegin(a)google.com&gt; >>> Signed-off-by: Kees Cook <keescook(a)chromium.org&gt; >>> --- >>> v2: >>> - make sure "From:" got sent correctly >>> --- >>> arch/x86/kernel/machine_kexec_64.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c >>> index 4eabc160696f..679cef0791cd 100644 >>> --- a/arch/x86/kernel/machine_kexec_64.c >>> +++ b/arch/x86/kernel/machine_kexec_64.c >>> @@ -279,5 +279,7 @@ void arch_crash_save_vmcoreinfo(void) >>> VMCOREINFO_SYMBOL(node_data); >>> VMCOREINFO_LENGTH(node_data, MAX_NUMNODES); >>> #endif >>> + vmcoreinfo_append_str("KERNELOFFSET=%lx\n", >>> + (unsigned long)&_text - __START_KERNEL); >>> } >> >> I've Cc:-ed Adrian Hunter, who has sent the following kaslr fixes for >> perf yesterday: >> >> http://lkml.org/lkml/2014/1/24/220 >> >> Adrian, is this patch the right solution from the perf tooling >> perspective? > > perf tools isn't a consumer of VMCOREINFO although I see VMCOREINFO > already has _stext which would be enough for many purposes. Yes - but let me explain where I'm coming from: I'd like the recent KASLR related perf /proc/kcore based annotation bug to be fixed properly. Currently I'm not sure about the status of it. In your fixes submission: Date: Fri, 24 Jan 2014 17:10:10 +0200 From: Adrian Hunter <adrian.hunter(a)intel.com&gt; Subject: [PATCH 0/8] perf tools: kaslr fixes you mentioned the following: "- mustn't use kcore if the kernel has moved" Does this that /proc/kcore annotation will not work if KASLR is active?

If yes then given that I expect most distros to turn on KASLR this would essentially make /proc/kcore useless on a large set of Linux systems. That would be suboptimal. Thanks, Ingo