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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 29/08/14 15:32, Stefan Bader wrote:
> On 29.08.2014 16:19, Andrew Cooper wrote:
>> On 29/08/14 09:37, Stefan Bader wrote:
>>> On 29.08.2014 00:42, Andrew Cooper wrote:
>>>> 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.
>>> machine_to_phys_mapping is set to that address but its not mapped inside the
>>> crash dump. Somehow vtop in crash handles translations. I need to have a 
>>> look at
>>> their code, I guess.
>>>
>>> Thanks,
>>> Stefan
>> What context is the crash dump?  If it is a Xen+dom0 kexec()d to native
>> linux, then the m2p should still be accessible given dom0's cr3.  If it
>> is some state copied off-host then you will need to adjust the copy to
>> include that virtual range.
> No its a domU dump of a PV guest taken with "xl dump-core" (or actually the
> result of on-crash trigger).

Ah - I believe the m2p lives in one of the Xen elf notes for a domain
coredump.  See what readelf -n shows.

~Andrew

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