From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] Solved the Xen PV/KASLR riddle Date: Thu, 28 Aug 2014 23:42:13 +0100 Message-ID: <53FFB045.9010809@citrix.com> References: <20140827204940.GA10556@laptop.dumpdata.com> <1409248903-19625-1-git-send-email-stefan.bader@canonical.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1409248903-19625-1-git-send-email-stefan.bader@canonical.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefan Bader , Konrad Rzeszutek Wilk Cc: David Vrabel , "xen-devel@lists.xensource.com" , Linux Kernel Mailing List , Kees Cook List-Id: xen-devel@lists.xenproject.org On 28/08/2014 19:01, Stefan Bader wrote: >>> So not much further... but then I think I know what I do next. Probably should >>> have done before. I'll replace the WARN_ON in vmalloc that triggers by a panic >>> and at least get a crash dump of that situation when it occurs. Then I can dig >>> in there with crash (really should have thought of that before)... >> I dug a bit in the code (arch/x86/xen/mmu.c) but there is nothing there >> that screams at me, so I fear I will have to wait until you get the crash >> and get some clues from that. > Ok, what a journey. So after long hours of painful staring at the code... > (and btw, if someone could tell me how the heck one can do a mfn_to_pfn > in crash, I really would appreaciate :-P) The M2P map lives in the Xen reserved virtual address space in each PV guest, and forms part of the PV ABI. It is mapped read-only, in the native width of the guest. 32bit PV (PAE) at 0xF5800000 64bit PV at 0xFFFF800000000000 This is represented by the MACH2PHYS_VIRT_START symbol from the Xen public header files. You should be able to blindly construct a pointer to it (if you have nothing better to hand), as it will be hooked into the guests pagetables before execution starts. Therefore, "MACH2PHYS_VIRT_START[(unsigned long)pfn]" ought to do in a pinch. ~Andrew