This method requires only valid CR3. It walks through
page tree starting from __START_KERNEL_map to get real
_stext and its physical address.
_stext_vmlinux has to be initialized. So, requesting it
by "st->_stext_vmlinux = UNINITIALIZED;" for sadump and
vmware backends. Other backends may use "--kaslr=auto"
to get similar effect.
Use this method as a default and IDTR base as a backup.
Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
Acked-by: Lianbo Jiang <lijiang@redhat.com>
Use LA57 bit in CR4 to check whether 5-level paging enabled.
Initialize machdep to 5-level paging operation mode used by
x86_64_kvtop.
Replaced *_get_cr3_idtr() set of functions by *_get_cr3_cr4_idtr().
[ kh: added malloc for p4d page ]
Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
Acked-by: Lianbo Jiang <lijiang@redhat.com>
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
Qemu and VMWare facilities rely only on CPU #0 to provide
CR3 and IDTR. But these registers can be not initialized
or clobbered, depending on the state of CPU. For example,
kernel can trigger triple fault by zeroing IDTR and doing
int3. This is used in Linux to reboot machine using triple
fault: "reboot=t" cmdline. In that case CPU which triggered
triple fault will have zeroed IDTR.
Generalize the method used by Sadump facility to analyze
every pair of registers from all available CPUs.
Create subfunctions for easy reading.
Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
Acked-by: Lianbo Jiang <lijiang@redhat.com>
We faced recently a memory dump collected by sadump where unused part
of register values are non-zero. For the crash dump, calculating
kaslr_offset fails because it is based on the assumption that unused
part of register values in the sadump format are always zero cleared.
The problem is that used and unused part of register values are
rigorously indistinguishable in the sadump format. Although there is
kernel data structure that represents a map between logical cpu
numbers and lapic ids, they cannot be used in order to calculate
kaslr_offset.
To fix this, we have no choice but use a trial-and-error approach: try
to use each entry of register values in order until we find a good
pair of cr3 and idtr by which we can refer to linux_banner symbol as
expected.
This fix is for the sadump specific issue, so there is no functional
change for the other crash dump formats.
[ lijiang: adjust the code indent. ]
Signed-off-by: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
Setting values of the arguments of calc_kaslr_offset() should be done
at the end of the function. Currently, they are set in the middle
where their values could still be changed according to
get_kaslr_offset_from_vmcoreinfo(). This behavior will be problematic
in the later commits when we implement a trial-and-error approach
because the value of kaslr_offset could be passed to the outside of
calc_kaslr_offset() unexpectedly. Thus, fix this first.
Signed-off-by: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
calculating phys_base and the mapped kernel offset for KASLR-enabled
kernels on SADUMP dumpfiles by using a technique developed by Takao
Indoh. Originally, the patchset included support for kdumps, but this
was dropped in v2, as it was deemed unnecessary due to the upstream
implementation of the "vmcoreinfo device" in QEMU. However, there
are still several reasons for which the vmcoreinfo device may not be
present at the time when a memory dump is taken from a VM, ranging
from a host running older QEMU/libvirt versions, to misconfigured VMs
or environments running Hypervisors that doesn't support this device.
This patchset generalizes the KASLR-related functions from sadump.c
and moves them to kaslr_helper.c, and makes kdump analysis fall back
to KASLR offset calculation if vmcoreinfo data is missing.
(slp@redhat.com)
Alexey Makhalov
HATAYAMA Daisuke
Dave Anderson