[Crash-utility] [PATCH v2] arm64: fix kernel memory map handling for kaslr-enabled kernel

Dave Anderson anderson at redhat.com
Wed May 25 15:44:23 UTC 2016



----- 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
  ...

  crash> kmem fffffdff80000000
  kmem: WARNING: cannot make virtual-to-physical translation: fffffdff80000000
  fffffdff80000000: kernel virtual address not found in mem map
  crash>
  
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

Dave




More information about the Crash-utility mailing list