Re: [Xen-devel] [PATCH] Solved the Xen PV/KASLR riddle

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel