[Crash-utility] [PATCH v2] arm64: fix kernel memory map handling for kaslr-enabled kernel
AKASHI Takahiro
takahiro.akashi at linaro.org
Thu May 26 08:37:54 UTC 2016
On Wed, May 25, 2016 at 11:44:23AM -0400, Dave Anderson wrote:
>
> ----- Original Message -----
> > >
> > > Are you using a mainline kernel (final v4.6, not -rcX)?
> >
> > Good point. When I configured my arm64 test system, I installed the latest
> > Fedora kernel available at the time (4.6.0-0.rc7.git2.1.fc25), but it is based
> > upon linux-4.5.tar.xz. I see now that there is a kernel-4.6.0-1.fc25 available
> > that is based upon linux-4.6.tar.xz. I'll update the system.
>
> Here's the output from the updated non-randomized live system:
>
> crash> sys
> KERNEL: /usr/lib/debug/lib/modules/4.6.0-1.fc25.aarch64/vmlinux
> DUMPFILE: /dev/crash
> CPUS: 8
> DATE: Wed May 25 11:30:06 2016
> UPTIME: 00:18:43
> LOAD AVERAGE: 0.01, 0.14, 0.17
> TASKS: 200
> NODENAME: apm-mustang-ev3-36.khw.lab.eng.bos.redhat.com
> RELEASE: 4.6.0-1.fc25.aarch64
> VERSION: #1 SMP Mon May 16 23:11:08 UTC 2016
> MACHINE: aarch64 (unknown Mhz)
> MEMORY: 16 GB
> crash> log
> ... [ cut ] ...
> [ 0.000000] Virtual kernel memory layout:
> [ 0.000000] modules : 0xfffffc0000000000 - 0xfffffc0008000000 ( 128 MB)
> [ 0.000000] vmalloc : 0xfffffc0008000000 - 0xfffffdfedfff0000 ( 2043 GB)
> [ 0.000000] .text : 0xfffffc0008080000 - 0xfffffc0008890000 ( 8256 KB)
> .rodata : 0xfffffc0008890000 - 0xfffffc0008c10000 ( 3584 KB)
> .init : 0xfffffc0008c10000 - 0xfffffc0008d50000 ( 1280 KB)
> .data : 0xfffffc0008d50000 - 0xfffffc0008eaac00 ( 1387 KB)
> [ 0.000000] vmemmap : 0xfffffdfee0000000 - 0xfffffdffe0000000 ( 4 GB maximum)
> 0xfffffdfee0000000 - 0xfffffdfee1000000 ( 16 MB actual)
> [ 0.000000] fixed : 0xfffffdfffe7d0000 - 0xfffffdfffec00000 ( 4288 KB)
> [ 0.000000] PCI I/O : 0xfffffdfffee00000 - 0xfffffdffffe00000 ( 16 MB)
> [ 0.000000] memory : 0xfffffe0000000000 - 0xfffffe0400000000 ( 16384 MB)
> ...
>
> The starting addresses are OK, but still the vmemmap range looks suspect:
>
> crash> help -m
> ... [ cut ] ...
> VA_BITS: 42
> userspace_top: 0000040000000000
> page_offset: fffffe0000000000
> vmalloc_start_addr: fffffc0008000000
> vmalloc_end: fffffdff5ffeffff
> modules_vaddr: fffffc0000000000
> modules_end: fffffc0007ffffff
> vmemmap_vaddr: fffffdff80000000 ???
> vmemmap_end: fffffdffffffffff
> kimage_text: fffffc0008080000
> kimage_end: fffffc0009070000
> kimage_voffset: 0000000000000000
> phys_offset: 4000000000
> ...
In my environment,
Virtual kernel memory layout:
modules : 0xffff000000000000 - 0xffff000008000000 ( 128 MB)
vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000 (129022 GB)
.text : 0xffff000008080000 - 0xffff0000087e0000 ( 7552 KB)
.rodata : 0xffff0000087e0000 - 0xffff000008b10000 ( 3264 KB)
.init : 0xffff000008b10000 - 0xffff000008c00000 ( 960 KB)
.data : 0xffff000008c00000 - 0xffff000008ca1e00 ( 648 KB)
.bss : 0xffff000008ca1e00 - 0xffff000008ce4b38 ( 268 KB)
fixed : 0xffff7dfffe7fd000 - 0xffff7dfffec00000 ( 4108 KB)
PCI I/O : 0xffff7dfffee00000 - 0xffff7dffffe00000 ( 16 MB)
vmemmap : 0xffff7e0000000000 - 0xffff800000000000 ( 2048 GB maximum)
0xffff7e0000000000 - 0xffff7e0000900000 ( 9 MB actual)
memory : 0xffff800000000000 - 0xffff800024000000 ( 576 MB)
and,
$ crash ...
KERNEL: ./vmlinux.0526_64_48_nok
DUMPFILE: vmcore.0526_64_48_nok
CPUS: 8 [OFFLINE: 7]
DATE: Thu May 26 12:04:05 2016
UPTIME: 00:00:49
LOAD AVERAGE: 0.13, 0.04, 0.01
TASKS: 100
NODENAME: buildroot_le
RELEASE: 4.6.0+
VERSION: #1 SMP PREEMPT Thu May 26 12:02:41 JST 2016
MACHINE: aarch64 (unknown Mhz)
MEMORY: 512 MB
PANIC: "sysrq: SysRq : Trigger a crash"
PID: 1050
COMMAND: "sh"
TASK: ffff800020679c00 [THREAD_INFO: ffff8000205fc000]
CPU: 0
STATE: TASK_RUNNING (SYSRQ)
crash> help -m
...
VA_BITS: 48
userspace_top: 0001000000000000
page_offset: ffff800000000000
vmalloc_start_addr: ffff000008000000
vmalloc_end: ffff7fdfdffeffff
modules_vaddr: ffff000000000000
modules_end: ffff000007ffffff
vmemmap_vaddr: ffff7fe000000000
vmemmap_end: ffff7fffffffffff
kimage_text: ffff000008080000
kimage_end: ffff000008de0000
kimage_voffset: fffeffff88000000
phys_offset: 80000000
>
> crash> kmem fffffdff80000000
> kmem: WARNING: cannot make virtual-to-physical translation: fffffdff80000000
> fffffdff80000000: kernel virtual address not found in mem map
> crash>
Yeah, I noticed this issue.
But the current crash doesn't support 4-level translation for 4KB now,
I changed the kernel configuration with 64KB page size and
with 48 bit VA (so 3-level), then confirmed that it just worked on
non-randomized kernel, but not on randomized kernel.
> The vmemmap address from the log reads OK:
>
> crash> kmem -p | head -10
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> fffffdfee0000000 4000000000 fffffe03dc99f430 1b 2 4003c referenced,uptodate,dirty,lru,swapbacked
> fffffdfee0000040 4000010000 fffffe03dc99f430 1c 2 4003c referenced,uptodate,dirty,lru,swapbacked
> fffffdfee0000080 4000020000 fffffe03dc99f430 1d 2 4003c referenced,uptodate,dirty,lru,swapbacked
> fffffdfee00000c0 4000030000 fffffe03dc99f430 1e 2 4003c referenced,uptodate,dirty,lru,swapbacked
> fffffdfee0000100 4000040000 fffffe03dc99f430 1f 2 4003c referenced,uptodate,dirty,lru,swapbacked
> fffffdfee0000140 4000050000 fffffe03dc99f430 20 2 40078 uptodate,dirty,lru,active,swapbacked
> fffffdfee0000180 4000060000 fffffe03dc99f430 21 2 4003c referenced,uptodate,dirty,lru,swapbacked
> fffffdfee00001c0 4000070000 fffffe03dc99f430 22 2 40078 uptodate,dirty,lru,active,swapbacked
> fffffdfee0000200 4000080000 0 0 1 400 reserved
> ... [ cut ] ...
> fffffdfee0fffd80 43fff60000 0 0 1 4000000000000400 reserved
> fffffdfee0fffdc0 43fff70000 0 0 1 4000000000000400 reserved
> fffffdfee0fffe00 43fff80000 0 0 1 4000000000000400 reserved
> fffffdfee0fffe40 43fff90000 0 0 1 4000000000000400 reserved
> fffffdfee0fffe80 43fffa0000 0 0 1 4000000000000400 reserved
> fffffdfee0fffec0 43fffb0000 0 0 1 4000000000000400 reserved
> fffffdfee0ffff00 43fffc0000 0 0 1 4000000000000400 reserved
> fffffdfee0ffff40 43fffd0000 0 0 1 4000000000000400 reserved
> fffffdfee0ffff80 43fffe0000 0 0 1 4000000000000400 reserved
> fffffdfee0ffffc0 43ffff0000 0 0 1 4000000000000400 reserved
> crash>
>
>
> And again, the page_offset is fffffe0000000000 with a kernel VA_BITS configuration of 42:
>
> kernel-4.6.0-aarch64.config:CONFIG_ARM64_VA_BITS_42=y
> kernel-4.6.0-aarch64.config:# CONFIG_ARM64_VA_BITS_48 is not set
> kernel-4.6.0-aarch64.config:CONFIG_ARM64_VA_BITS=42
I think it looks OK.
Thanks,
-Takahiro AKASHI
> Dave
>
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
--
Thanks,
-Takahiro AKASHI
More information about the Crash-utility
mailing list