* Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: > On 25/01/14 09:47, Ingo Molnar wrote: > > > > * Kees Cook <keescook@xxxxxxxxxxxx> wrote: > > > >> From: Eugene Surovegin <surovegin@xxxxxxxxxx> > >> > >> Include kASLR offset in VMCOREINFO ELF notes to assist in debugging. > >> > >> Signed-off-by: Eugene Surovegin <surovegin@xxxxxxxxxx> > >> Signed-off-by: Kees Cook <keescook@xxxxxxxxxxxx> > >> --- > >> 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@xxxxxxxxx> 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility