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

[AKASHI Takahiro]

Dave,

On Mon, May 23, 2016 at 09:25:37AM -0400, Dave Anderson wrote:
> 
> ----- 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?

Yes, it is! That is what Ard has managed to do in his series of
KASLR-related patches.

-Takahiro AKASHI

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

-- 
Thanks,
-Takahiro AKASHI