11:13 a.m.
Hello Mikhail, Philipp and Gerald,
For the first time today I'm testing a 5.2.0-0.rc1 kernel that has
been configured with CONFIG_RANDOMIZE_BASE=y, and I have verified
that it runs live using the KERNELOFFSET value from the /proc/kcore
VMCOREINFO as the --kalsr argument.
For live system analysis, it seems that the existing kaslr
code in symbols.c should be able to calculate the offset
by comparing the _stext values from /proc/kallsyms and the
the vmlinux file. But obviously it doesn't, although I
haven't investigate why not.
Also, I can't create a kdump dumpfile, so I can't test that,
so it's not clear whether the initial patchset also requires
the -kaslr argument for vmcores?
Anyway, are you guys planning to post a follow-on patch to make
things work automagically both live and with kdumps?
Thanks,
Dave
----- Original Message -----
Add --kaslr support for s390x kernels configured with
CONFIG_RANDOMIZE_BASE. Only kdumps or ELF dumps with
vmcoreinfo are supported.
Suggested-by: Gerald Schaefer <gerald schaefer de ibm com>
Signed-off-by: Mikhail Zaslonko <zaslonko linux ibm com>
---
help.c | 2 +-
main.c | 3 ++-
symbols.c | 9 +++++----
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/help.c b/help.c
index ba15dec..47058ed 100644
--- a/help.c
+++ b/help.c
@@ -335,7 +335,7 @@ char *program_usage_info[] = {
" and verification. The default count is 32768.",
"",
" --kaslr offset | auto",
- " If an x86 or x86_64 kernel was configured with
CONFIG_RANDOMIZE_BASE,",
+ " If x86, x86_64 or s390x kernel was configured with
CONFIG_RANDOMIZE_BASE,",
" the offset value is equal to the difference between the symbol values
",
" compiled into the vmlinux file and their relocated KASLR value. If",
" set to auto, the KASLR offset value will be automatically
calculated.",
diff --git a/main.c b/main.c
index cd282cd..83ccd31 100644
--- a/main.c
+++ b/main.c
@@ -227,7 +227,8 @@ main(int argc, char **argv)
}
} else if (STREQ(long_options[option_index].name, "kaslr")) {
if (!machine_type("X86_64") &&
- !machine_type("ARM64") && !machine_type("X86"))
+ !machine_type("ARM64") && !machine_type("X86")
&&
+ !machine_type("S390X"))
error(INFO, "--kaslr not valid "
"with this machine type.\n");
else if (STREQ(optarg, "auto"))
diff --git a/symbols.c b/symbols.c
index 77f45f9..1ed75fe 100644
--- a/symbols.c
+++ b/symbols.c
@@ -593,8 +593,8 @@ kaslr_init(void)
{
char *string;
- if ((!machine_type("X86_64") && !machine_type("ARM64")
&& !machine_type("X86")) ||
- (kt->flags & RELOC_SET))
+ if ((!machine_type("X86_64") && !machine_type("ARM64")
&& !machine_type("X86") &&
+ !machine_type("S390X")) || (kt->flags & RELOC_SET))
return;
/*
@@ -751,7 +751,8 @@ store_symbols(bfd *abfd, int dynamic, void *minisyms, long symcount,
fromend, size, store);
} else if (!(kt->flags & RELOC_SET))
kt->flags |= RELOC_FORCE;
- } else if (machine_type("X86_64") || machine_type("ARM64")) {
+ } else if (machine_type("X86_64") || machine_type("ARM64") ||
+ machine_type("S390X")) {
if ((kt->flags2 & RELOC_AUTO) && !(kt->flags & RELOC_SET))
derive_kaslr_offset(abfd, dynamic, from,
fromend, size, store);
@@ -823,7 +824,7 @@ store_sysmap_symbols(void)
strerror(errno));
if (!machine_type("X86") && !machine_type("X86_64")
&&
- !machine_type("ARM64"))
+ !machine_type("ARM64") && !machine_type("S390X"))
kt->flags &= ~RELOC_SET;
first = 0;
--
2.16.4
2:38 p.m.
New subject: [PATCH 0/1] Add --kaslr support for s390x
----- Original Message -----
Hello Mikhail, Philipp and Gerald,
For the first time today I'm testing a 5.2.0-0.rc1 kernel that has
been configured with CONFIG_RANDOMIZE_BASE=y, and I have verified
that it runs live using the KERNELOFFSET value from the /proc/kcore
VMCOREINFO as the --kalsr argument.
For live system analysis, it seems that the existing kaslr
code in symbols.c should be able to calculate the offset
by comparing the _stext values from /proc/kallsyms and the
the vmlinux file. But obviously it doesn't, although I
haven't investigate why not.
Also, I can't create a kdump dumpfile, so I can't test that,
so it's not clear whether the initial patchset also requires
the -kaslr argument for vmcores?
Anyway, are you guys planning to post a follow-on patch to make
things work automagically both live and with kdumps?
Thanks,
Dave
Just to follow-up...
The current KASLR-checking code in kaslr_init() looks for an x86-only variable,
so for s390x, this simple patch makes live system work without --kalsr:
--- a/symbols.c
+++ b/symbols.c
@@ -609,6 +609,12 @@ kaslr_init(void)
st->_stext_vmlinux = UNINITIALIZED;
}
+ if (machine_type("S390X") && /* Linux 5.2 */
+ (symbol_value_from_proc_kallsyms("__kaslr_offset") != BADVAL)) {
+ kt->flags2 |= (RELOC_AUTO|KASLR);
+ st->_stext_vmlinux = UNINITIALIZED;
+ }
+
if (QEMU_MEM_DUMP_NO_VMCOREINFO()) {
if (KDUMP_DUMPFILE() && kdump_kaslr_check()) {
kt->flags2 |= KASLR_CHECK;
Proof of the pudding:
# ./crash
crash 7.2.6++
Copyright (C) 2002-2019 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "s390x-ibm-linux-gnu"...
WARNING: kernel relocated [1239MB]: patching 65462 gdb minimal_symbol values
KERNEL: /usr/lib/debug/lib/modules/5.2.0-0.rc1.1.elrdy.s390x/vmlinux
DUMPFILE: /proc/kcore
CPUS: 2
DATE: Wed May 22 15:29:37 2019
UPTIME: 04:04:45
LOAD AVERAGE: 0.22, 0.10, 0.08
TASKS: 138
NODENAME: ibm-z-113.rhts.eng.bos.redhat.com
RELEASE: 5.2.0-0.rc1.1.elrdy.s390x
VERSION: #1 SMP Mon May 20 22:23:41 EDT 2019
MACHINE: s390x (unknown Mhz)
MEMORY: 2 GB
PID: 8322
COMMAND: "crash"
TASK: 69739000 [THREAD_INFO: 69739000]
CPU: 1
STATE: TASK_RUNNING (ACTIVE)
crash>
And it appears that kdump vmcores with KERNELOFFSET should just work, no?
Dave
4:06 a.m.
New subject: [PATCH 0/1] Add --kaslr support for s390x
Hi Dave,
On Wed, 22 May 2019 15:38:55 -0400 (EDT)
Dave Anderson <anderson(a)redhat.com> wrote:
----- Original Message -----
>
> Hello Mikhail, Philipp and Gerald,
>
> For the first time today I'm testing a 5.2.0-0.rc1 kernel that has
> been configured with CONFIG_RANDOMIZE_BASE=y, and I have verified
> that it runs live using the KERNELOFFSET value from the /proc/kcore
> VMCOREINFO as the --kalsr argument.
>
> For live system analysis, it seems that the existing kaslr
> code in symbols.c should be able to calculate the offset
> by comparing the _stext values from /proc/kallsyms and the
> the vmlinux file. But obviously it doesn't, although I
> haven't investigate why not.
the patches we sent you were the absolute minimum necessary to be able to debug
dumps. I think no one of us ever tried to debug a live system. So I'm not all
that surprised that there are cases where it does not work.
For what I know, we currently can only debug dumps where the KERNELOFFSET can
be read from vmcoreinfo. So basically kdump and ELF with vmcoreinfo in the
PT_NOTE segment. For other dumps we have a workaround using zgetdump to mount
and translate the dumps to ELF.
> Also, I can't create a kdump dumpfile, so I can't test
that,
> so it's not clear whether the initial patchset also requires
> the -kaslr argument for vmcores?
>
> Anyway, are you guys planning to post a follow-on patch to make
> things work automagically both live and with kdumps?
I actually wanted to talk to about that last week when I was in Westford but
you were on vacation...
The short answer is yes, we will post more patches. We 'only' need to find some
time to do it. I actually planned to take a look at it after Patch Ready
Deadline is over but after the loss of Martin we now first have to see how
everything will be arranged in the team.
> Thanks,
> Dave
Just to follow-up...
The current KASLR-checking code in kaslr_init() looks for an x86-only variable,
so for s390x, this simple patch makes live system work without --kalsr:
--- a/symbols.c
+++ b/symbols.c
@@ -609,6 +609,12 @@ kaslr_init(void)
st->_stext_vmlinux = UNINITIALIZED;
}
+ if (machine_type("S390X") && /* Linux 5.2 */
+ (symbol_value_from_proc_kallsyms("__kaslr_offset") != BADVAL)) {
+ kt->flags2 |= (RELOC_AUTO|KASLR);
+ st->_stext_vmlinux = UNINITIALIZED;
+ }
+
if (QEMU_MEM_DUMP_NO_VMCOREINFO()) {
if (KDUMP_DUMPFILE() && kdump_kaslr_check()) {
kt->flags2 |= KASLR_CHECK;
Wow, great. That will definitely help!
Thanks
Philipp
Proof of the pudding:
# ./crash
crash 7.2.6++
Copyright (C) 2002-2019 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "s390x-ibm-linux-gnu"...
WARNING: kernel relocated [1239MB]: patching 65462 gdb minimal_symbol values
KERNEL: /usr/lib/debug/lib/modules/5.2.0-0.rc1.1.elrdy.s390x/vmlinux
DUMPFILE: /proc/kcore
CPUS: 2
DATE: Wed May 22 15:29:37 2019
UPTIME: 04:04:45
LOAD AVERAGE: 0.22, 0.10, 0.08
TASKS: 138
NODENAME: ibm-z-113.rhts.eng.bos.redhat.com
RELEASE: 5.2.0-0.rc1.1.elrdy.s390x
VERSION: #1 SMP Mon May 20 22:23:41 EDT 2019
MACHINE: s390x (unknown Mhz)
MEMORY: 2 GB
PID: 8322
COMMAND: "crash"
TASK: 69739000 [THREAD_INFO: 69739000]
CPU: 1
STATE: TASK_RUNNING (ACTIVE)
crash>
And it appears that kdump vmcores with KERNELOFFSET should just work, no?
Dave
2014
days inactive
2015
days old
devel@lists.crash-utility.osci.io
2 comments
2 participants
participants (2)
-
Dave Anderson -
Philipp Rudo