date:20160525

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

2016-05-25 Thread AKASHI Takahiro

On Tue, May 24, 2016 at 09:35:54AM -0400, Dave Anderson wrote:
> 
> 
> - Original Message -
> > > > 
> > > > Now that PHYS_OFFSET is defined as "memstart_addr",  we can get the 
> > > > value
> > > > if we can access this symbol (on a live system).
> > > 
> > > When PHYS_OFFSET/memstart_addr is bumped up from the actual base of  
> > > physical
> > > memory, is the physical memory below it no longer used/accessible?
> > 
> > Yes, it is! That is what Ard has managed to do in his series of
> > KASLR-related patches.
> 
> How is it accessed via a kernel virtual address?  Or is only accessible when
> mapped into a vmalloc() or user-space address?

Through a linear(unity) mapping above PAGE_OFFSET.

-Takahiro AKASHI

> Dave
> 
> --
> Crash-utility mailing list
> Crash-utility@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

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

2016-05-25 Thread AKASHI Takahiro

On Tue, May 24, 2016 at 01:59:06PM -0400, Dave Anderson wrote:
> 
> - Original Message -
> > Yet some issues, but ...
> >
> 
> Hi Takahiro,
> 
> Here are my general comments on my testing of the v2 patch, followed 
> by a few comments in the patch itself. 

Thank you for your quick review/testing, again.

> First, the combination of the new memory map layout and KASLR is somewhat
> confusing.  I am testing your patch on a 4.6.0-0.rc7.git2.1.fc25 kernel
> that has this configuration:

Right. I use the "kaslr kernel" or "kaslr-enabled kernel" in two
meanings (almost interchangeably):
   - kernel with a new memory map, that is v4.6 or later
   - kernel that has ability of KASLR (configured with CONFIG_RANDOMIZE_RAM)

When we talked offline, you mentioned the possibility of backporting
KASLR to older kernel, so I hesitated to use "v4.6 or later".
But I think that we'd better use "v4.6 or later" for a clarification
for now.

>   config-arm64:# CONFIG_RANDOMIZE_BASE is not set
> 
> So KASLR doesn't really enter into the picture.  But when bringing
> up the crash session, it shows the "kaslr kernel" WARNING:
> 
>   # ./crash
>   
>   crash 7.1.5++
>   Copyright (C) 2002-2016  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.
>
>   WARNING: kimage_voffset not identified for kaslr kernel
>   GNU gdb (GDB) 7.6
>   Copyright (C) 2013 Free Software Foundation, Inc.
>   License GPLv3+: GNU GPL version 3 or later 
> 
>   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 "aarch64-unknown-linux-gnu"...
>   
> KERNEL: 
> /usr/lib/debug/lib/modules/4.6.0-0.rc7.git2.1.fc25.aarch64/vmlinux
>   DUMPFILE: /dev/crash
>   CPUS: 8
>   DATE: Tue May 24 10:08:08 2016
> UPTIME: 11 days, 18:32:41
>   LOAD AVERAGE: 0.17, 0.09, 0.12
>  TASKS: 197
>   NODENAME: apm-mustang-ev3-36.khw.lab.eng.bos.redhat.com
>RELEASE: 4.6.0-0.rc7.git2.1.fc25.aarch64
>VERSION: #1 SMP Thu May 12 13:28:43 UTC 2016
>MACHINE: aarch64  (unknown Mhz)
> MEMORY: 16 GB
>PID: 7556
>COMMAND: "crash"
>   TASK: fe00beb45400  [THREAD_INFO: fe00beb98000]
>CPU: 7
>  STATE: TASK_RUNNING (ACTIVE)
>   
>   crash>
>   
> Why show that WARNING in this case?  I understant that it's not 
> stashed during early initialization:

If we don't know kimage_voffset, we can't analyze the contents of
memory (live or kdump).

>   crash> help -m
>  flags: 104000c5 
> (KSYMS_START|VM_L2_64K|VMEMMAP|IRQ_STACKS|MACHDEP_BT_TEXT|NEW_VMEMMAP)
>   ... [ cut ] ...
>memory map layout: new  <--- BTW, this is redundant/not-a-member, 
> and we've got NEW_VMEMMAP
>  VA_BITS: 42
>userspace_top: 0400
>  page_offset: fe00
>   vmalloc_start_addr: fc000800
>  vmalloc_end: fdff5ffe
>modules_vaddr: fc00
>  modules_end: fc0007ff
>vmemmap_vaddr: fdff8000
>  vmemmap_end: fdff
>  kimage_text: fc000808
>   kimage_end: fc000907
>   kimage_voffset: <-- available if kernel is not 
> randomized
>  phys_offset: 40
>   ...
>   
> But it can be read:
>   
>   crash> px kimage_voffset
>   kimage_voffset = $1 = 0xfbc00800
>   crash>
>
> SO because it wasn't determined during session initialization,
> it falls into the "no randomness" section of arm64_VTOP():

Exactly.

>   ulong
>   arm64_VTOP(ulong addr)
>   {
>   if (!(machdep->flags & NEW_VMEMMAP) ||
>   (addr >= machdep->machspec->page_offset)) {
>   return machdep->machspec->phys_offset
>   + (addr - machdep->machspec->page_offset);
>   } else {
>   if (machdep->machspec->kimage_voffset)
>   return addr - machdep->machspec->kimage_voffset;
>   else /* no randomness */
>   return machdep->machspec->phys_offset
>

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

2016-05-25 Thread Dave Anderson



- Original Message -
> On Tue, May 24, 2016 at 09:35:54AM -0400, Dave Anderson wrote:
> > 
> > 
> > - Original Message -
> > > > > 
> > > > > Now that PHYS_OFFSET is defined as "memstart_addr",  we can get the 
> > > > > value
> > > > > if we can access this symbol (on a live system).
> > > > 
> > > > When PHYS_OFFSET/memstart_addr is bumped up from the actual base of 
> > > > physical
> > > > memory, is the physical memory below it no longer used/accessible?
> > > 
> > > Yes, it is! That is what Ard has managed to do in his series of
> > > KASLR-related patches.
> > 
> > How is it accessed via a kernel virtual address?  Or is only accessible when
> > mapped into a vmalloc() or user-space address?
> 
> Through a linear(unity) mapping above PAGE_OFFSET.

I'm still confused...

Does PAGE_OFFSET+0 still refer to PHYS_OFFSET?  I'm trying to wrap my head 
around 
how __virt_to_phys() would work for the memory below the bumped-up PHYS_OFFSET.

Dave


 

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

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

2016-05-25 Thread Dave Anderson


- Original Message -
> On Tue, May 24, 2016 at 01:59:06PM -0400, Dave Anderson wrote:
> > 
> > - Original Message -
> > > Yet some issues, but ...
> > >
> > 
> > Hi Takahiro,
> > 
> > Here are my general comments on my testing of the v2 patch, followed
> > by a few comments in the patch itself.
> 
> Thank you for your quick review/testing, again.
> 
> > First, the combination of the new memory map layout and KASLR is somewhat
> > confusing.  I am testing your patch on a 4.6.0-0.rc7.git2.1.fc25 kernel
> > that has this configuration:
> 
> Right. I use the "kaslr kernel" or "kaslr-enabled kernel" in two
> meanings (almost interchangeably):
>- kernel with a new memory map, that is v4.6 or later
>- kernel that has ability of KASLR (configured with CONFIG_RANDOMIZE_RAM)
> 
> When we talked offline, you mentioned the possibility of backporting
> KASLR to older kernel, so I hesitated to use "v4.6 or later".
> But I think that we'd better use "v4.6 or later" for a clarification
> for now.
 
Actually I was thinking more along the lines of the new vmemmap stuff
being backported.  But it looks like that would be impossible without
also bringing along "kimage_voffset".  


> >   config-arm64:# CONFIG_RANDOMIZE_BASE is not set
> > 
> > So KASLR doesn't really enter into the picture.  But when bringing
> > up the crash session, it shows the "kaslr kernel" WARNING:
> > 
> >   # ./crash
> >   
> >   crash 7.1.5++
> >   Copyright (C) 2002-2016  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.
> >
> >   WARNING: kimage_voffset not identified for kaslr kernel
> >   GNU gdb (GDB) 7.6
> >   Copyright (C) 2013 Free Software Foundation, Inc.
> >   License GPLv3+: GNU GPL version 3 or later
> >   
> >   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 "aarch64-unknown-linux-gnu"...
> >   
> > KERNEL:
> > /usr/lib/debug/lib/modules/4.6.0-0.rc7.git2.1.fc25.aarch64/vmlinux
> >   DUMPFILE: /dev/crash
> >   CPUS: 8
> >   DATE: Tue May 24 10:08:08 2016
> > UPTIME: 11 days, 18:32:41
> >   LOAD AVERAGE: 0.17, 0.09, 0.12
> >  TASKS: 197
> >   NODENAME: apm-mustang-ev3-36.khw.lab.eng.bos.redhat.com
> >RELEASE: 4.6.0-0.rc7.git2.1.fc25.aarch64
> >VERSION: #1 SMP Thu May 12 13:28:43 UTC 2016
> >MACHINE: aarch64  (unknown Mhz)
> > MEMORY: 16 GB
> >PID: 7556
> >COMMAND: "crash"
> >   TASK: fe00beb45400  [THREAD_INFO: fe00beb98000]
> >CPU: 7
> >  STATE: TASK_RUNNING (ACTIVE)
> >   
> >   crash>
> >   
> > Why show that WARNING in this case?  I understant that it's not
> > stashed during early initialization:
> 
> If we don't know kimage_voffset, we can't analyze the contents of
> memory (live or kdump).

I understand.  But clearly that's not the case with my system above that
does not have CONFIG_RANDOMIZE_BASE configured, so the warning message
is nonsensical/confusing.  That's why I was speculating about perhaps
having kdump export a VMCOREINFO_CONFIG(RANDOMIZE_BASE) so that it is 
readily apparent.

> 
> >   crash> help -m
> >  flags: 104000c5
> >  
> > (KSYMS_START|VM_L2_64K|VMEMMAP|IRQ_STACKS|MACHDEP_BT_TEXT|NEW_VMEMMAP)
> >   ... [ cut ] ...
> >memory map layout: new  <--- BTW, this is
> >redundant/not-a-member, and we've got NEW_VMEMMAP
> >  VA_BITS: 42
> >userspace_top: 0400
> >  page_offset: fe00
> >   vmalloc_start_addr: fc000800
> >  vmalloc_end: fdff5ffe
> >modules_vaddr: fc00
> >  modules_end: fc0007ff
> >vmemmap_vaddr: fdff8000
> >  vmemmap_end: fdff
> >  kimage_text: fc000808
> >   kimage_end: fc000907
> >   kimage_voffset: <-- available if kernel is
> >   not randomized
> >  phys_offset: 40
> >   ...
> >   
> > But it can be read:
> >   
> >   cras

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

2016-05-25 Thread Dave Anderson



- 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.00] Virtual kernel memory layout:
  [0.00] modules : 0xfc00 - 0xfc000800   (   
128 MB)
  [0.00] vmalloc : 0xfc000800 - 0xfdfedfff   (  
2043 GB)
  [0.00]   .text : 0xfc000808 - 0xfc000889   (  
8256 KB)
 .rodata : 0xfc000889 - 0xfc0008c1   (  
3584 KB)
   .init : 0xfc0008c1 - 0xfc0008d5   (  
1280 KB)
   .data : 0xfc0008d5 - 0xfc0008eaac00   (  
1387 KB)
  [0.00] vmemmap : 0xfdfee000 - 0xfdffe000   ( 
4 GB maximum)
   0xfdfee000 - 0xfdfee100   (
16 MB actual)
  [0.00] fixed   : 0xfdfffe7d - 0xfdfffec0   (  
4288 KB)
  [0.00] PCI I/O : 0xfdfffee0 - 0xfde0   (
16 MB)
  [0.00] memory  : 0xfe00 - 0xfe04   ( 
16384 MB)
  ...
  
The starting addresses are OK, but still the vmemmap range looks suspect:
  
  crash> help -m
  ... [ cut ] ...
 VA_BITS: 42
   userspace_top: 0400
 page_offset: fe00
  vmalloc_start_addr: fc000800
 vmalloc_end: fdff5ffe
   modules_vaddr: fc00
 modules_end: fc0007ff
   vmemmap_vaddr: fdff8000  ???
 vmemmap_end: fdff
 kimage_text: fc000808
  kimage_end: fc000907
  kimage_voffset: 
 phys_offset: 40
  ...

  crash> kmem fdff8000
  kmem: WARNING: cannot make virtual-to-physical translation: fdff8000
  fdff8000: 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
  fdfee000   40 fe03dc99f430   1b  2 4003c 
referenced,uptodate,dirty,lru,swapbacked
  fdfee040   41 fe03dc99f430   1c  2 4003c 
referenced,uptodate,dirty,lru,swapbacked
  fdfee080   42 fe03dc99f430   1d  2 4003c 
referenced,uptodate,dirty,lru,swapbacked
  fdfee0c0   43 fe03dc99f430   1e  2 4003c 
referenced,uptodate,dirty,lru,swapbacked
  fdfee100   44 fe03dc99f430   1f  2 4003c 
referenced,uptodate,dirty,lru,swapbacked
  fdfee140   45 fe03dc99f430   20  2 40078 
uptodate,dirty,lru,active,swapbacked
  fdfee180   46 fe03dc99f430   21  2 4003c 
referenced,uptodate,dirty,lru,swapbacked
  fdfee1c0   47 fe03dc99f430   22  2 40078 
uptodate,dirty,lru,active,swapbacked
  fdfee200   4800  1 400 reserved
  ... [ cut ] ...
  fdfee0fffd80   43fff600  1 
4400 reserved
  fdfee0fffdc0   43fff700  1 
4400 reserved
  fdfee0fffe00   43fff800  1 
4400 reserved
  fdfee0fffe40   43fff900  1 
4400 reserved
  fdfee0fffe80   43fffa00  1 
4400 reserved
  fdfee0fffec0   43fffb00  1 
4400 reserved
  fdfee000   43fffc00  1 
4400 reserved
  fdfee040   43fffd00  1 
4400 reserved
  fdfee080   43fffe00  1 
4400 reserved
  fdfee0c0   4300  1 
4400 reserved
  crash>


And again, the page_offset is fe00 with a kernel VA_BITS 
configuration of 42:

  kernel-

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

2016-05-25 Thread Pratyush Anand

On 24/05/2016:01:59:06 PM, Dave Anderson wrote:
> 
> 
> - Original Message -
> > Yet some issues, but ...
> >
> 
> Hi Takahiro,
> 
> Here are my general comments on my testing of the v2 patch, followed 
> by a few comments in the patch itself. 
> 
> First, the combination of the new memory map layout and KASLR is somewhat
> confusing.  I am testing your patch on a 4.6.0-0.rc7.git2.1.fc25 kernel
> that has this configuration:
> 
>   config-arm64:# CONFIG_RANDOMIZE_BASE is not set
> 
> So KASLR doesn't really enter into the picture.  But when bringing
> up the crash session, it shows the "kaslr kernel" WARNING:
> 
>   # ./crash
>   
>   crash 7.1.5++
>   Copyright (C) 2002-2016  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.
>
>   WARNING: kimage_voffset not identified for kaslr kernel
>   GNU gdb (GDB) 7.6
>   Copyright (C) 2013 Free Software Foundation, Inc.
>   License GPLv3+: GNU GPL version 3 or later 
> 
>   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 "aarch64-unknown-linux-gnu"...
>   
> KERNEL: 
> /usr/lib/debug/lib/modules/4.6.0-0.rc7.git2.1.fc25.aarch64/vmlinux
>   DUMPFILE: /dev/crash
>   CPUS: 8
>   DATE: Tue May 24 10:08:08 2016
> UPTIME: 11 days, 18:32:41
>   LOAD AVERAGE: 0.17, 0.09, 0.12
>  TASKS: 197
>   NODENAME: apm-mustang-ev3-36.khw.lab.eng.bos.redhat.com
>RELEASE: 4.6.0-0.rc7.git2.1.fc25.aarch64
>VERSION: #1 SMP Thu May 12 13:28:43 UTC 2016
>MACHINE: aarch64  (unknown Mhz)
> MEMORY: 16 GB
>PID: 7556
>COMMAND: "crash"
>   TASK: fe00beb45400  [THREAD_INFO: fe00beb98000]
>CPU: 7
>  STATE: TASK_RUNNING (ACTIVE)
>   
>   crash>

Do not know whats missing, I am yet not able to reach "crash>" prompt. I have
crash utility having this patch on top of "commit
8ceb1ac628bf6a0a7f0bbfff030ec93081bca4cd" [1]. I have kernel code 
v4.6+kexec-v15 [2].

In my .config:
# CONFIG_KASAN is not set
# CONFIG_RANDOMIZE_BASE is not set

This is what I get:

[root@dhcppc15 crash]# ./crash /lib/modules/4.6.0+/build/vmlinux 
/var/crash/127.0.0.1-2016-05-26-09\:40\:05/vmcore

crash 7.1.5++
Copyright (C) 2002-2016  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 
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 "aarch64-unknown-linux-gnu"...

crash: read error: kernel virtual address: fc0008b80fd8  type: "possible"
WARNING: cannot read cpu_possible_map
crash: read error: kernel virtual address: fc0008b80dd8  type: "present"
WARNING: cannot read cpu_present_map
crash: read error: kernel virtual address: fc0008b80bd8  type: "online"
WARNING: cannot read cpu_online_map
crash: read error: kernel virtual address: fc0008b811d8  type: "active"
WARNING: cannot read cpu_active_map
crash: read error: kernel virtual address: fc00091f6c78  type: 
"shadow_timekeeper xtime_sec"
crash: read error: kernel virtual address: fc0008b9223c  type: "init_uts_ns"
crash: /lib/modules/4.6.0+/build/vmlinux and 
/var/crash/127.0.0.1-2016-05-26-09:40:05/vmcore do not match!

Usage:

  crash [OPTION]... NAMELIST MEMORY-IMAGE[@ADDRESS] (dumpfile form)
  crash [OPTION]... [NAMELIST]  (live syste

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

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

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

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

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

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

6 matches

Site Navigation

Mail list logo

Footer information