----- Original Message -----
[PATCH] Add --kaslr=auto option to automatically detect kaslr
offset.
This patch adds the --kaslr=auto option. When set crash will
attempt to find the aslr offset by comparing the _stext symbol
in the vmlinux file to the _stext symbol in the vmcoreinfo.
When the kernel is updated to include the kernel aslr offset
in the vmcoreinfo, that should be used instead of this indirect
method.
Hi Andy,
I've modified this patch in several locations:
- The RELOC_AUTO #define overruns the kt->flags field for 32-bit
kernels, so I've bitten the bullet and appended a a new kt->flags2
field to hold it. I avoid changing any of the global data
structures (besides adding to the end of them) to maintain an ABI
for extension modules.
- I added an additional KASLR flag that gets turned on by --kaslr
offset or auto. It doesn't serve a vital purpose now, other than
to differentiate relocation done by x86 kernels vs KASLR-only kernels.
It will presumably be useful when/if the new proposed KERNELOFFSET
vmcoreinfo offset makes it into the kernel.
- The dump_kernel_table() function called by "help -k" is updated to
show the two new flags, and also to show a translation of the
kt->relocate field in the case of (kt->flags2 & KASLR).
- The "kernel relocated" gdb-patch message will also be shown in the
case of "--kaslr=auto" so the user will be aware of what the calculated
offset was determined to be. In the case of "--kaslr=<offset>", it is
still not displayed.
- The derive_kaslr_offset() will return immediately upon finding the
_stext symbol, instead of cycling through the remaining symbols.
- Updated the --kaslr description in help.c for "crash --help".
- Both instances of the vmcoreinfo_read_string() call in is_netdump()
and is_diskdump() were modified to handle NULL returns, which can
happen with older kdumps.
- The vmcoreinfo_read_string() function in diskdump.c needed a small
fix to prevent a SIGSEGV if the diskdump header version is less than 3.
- I added a new "symbol_value_from_proc_kallsyms()" function that is
called by derive_kaslr_offset() in the case of live systems. The value
returned is used as an alternative to kt->vmcoreinfo._stext_SYMBOL.
So, with all of the above in place, off the top of my head these would
be the remaining issues:
(1) Support for the KERNELOFFSET vmcoreinfo entry, which if it exists,
would be used to mimic/obviate the --kalsr=auto functionality.
(2) Introducing/allowing --kalsr support for 32-bit x86 kernels.
(3) Support for compressed KASLR kdumps when they become supported by the
makedumpfile facility; as far as crash is concerned, though, it should
"just work".
I appreciate all your work on this issue.
Queued for crash-7.0.6 -- GitHub commit:
https://github.com/crash-utility/crash/commit/b8db9a76e96a1e7cec4d063ffed...
Thanks,
Dave