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

Dave Anderson anderson at redhat.com
Mon May 23 13:25:37 UTC 2016



----- Original Message -----
> On Fri, May 20, 2016 at 03:06:39PM -0400, Dave Anderson wrote:
> > 
> > 
> > Hi Takahiro,
> > 
> > Welcome to the mailing list -- you are a most valuable addition.
> > 
> > To others in the list, Takahiro and I have been communicating offline
> > for a couple weeks, and I convinced him to join us.  He works on both
> > kexec-tools and the crash utility for Linaro on the ARM64 architecture.
> > If you are unaware, in Linux 4.6 there was a major change in the ARM64
> > virtual memory layout, complicated by the layering of KASLR on top of it.
> > The new VM has broken crash utility support completely, and Takahiro is
> > tackling both.
> > 
> > My comments and questions on the v1 patch follow...
> > 
> > ----- Original Message -----
> > > Hi,
> > > 
> > > This patch is still rough-edged, but please review it and
> > > any comments are very welcome.
> > > I will try to fix the known issues before I submit a new
> > > version of kexec/kdump patch for v4.7 merge window.
> > > 
> > > Thanks,
> > > -Takahiro AKASHI
> > > 
> > > ===8<===
> > > >From fdc7c881d98ef00ed1ff38a058b4913a1d5bcda6 Mon Sep 17 00:00:00 2001
> > > From: AKASHI Takahiro <takahiro.akashi at linaro.org>
> > > Date: Mon, 16 May 2016 17:31:55 +0900
> > > Subject: [PATCH v1] arm64: fix kernel memory map handling for
> > > kaslr-enabled
> > >  kernel
> > > 
> > > In kernel v4.6, Kernel ASLR (KASLR) is supported on arm64, and the start
> > > address of the kernel image can be randomized if CONFIG_RANDOMIZE_BASE is
> > > enabled.
> > > Even worse, the kernel image is no more mapped in the linear mapping, but
> > > in vmalloc area (i.e. below PAGE_OFFSET).
> > > 
> > > Now, according to the kernel's memory.h, converting a virtual address to
> > > a physical address should be done like below:
> > > 
> > > 	phys_addr_t __x = (phys_addr_t)(x);                             \
> > > 	__x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET :   \
> > > 				 (__x - kimage_voffset); })
> > > 
> > > Please note that PHYS_OFFSET is no more equal to the start address of
> > > the first usable memory block in SYSTEM RAM due to the fact mentioned
> > > above.
> > 
> > So it is no longer possible to use /proc/iomem if KASLR is enabled
> > on a live system?   That being the case, we need a way for root to
> > be able to determine what it is for live system analysis.
> 
> 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?

Dave




More information about the Crash-utility mailing list