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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <54008F05.9090403@canonical.com>
Date:	Fri, 29 Aug 2014 16:32:37 +0200
From:	Stefan Bader <stefan.bader@...onical.com>
To:	Andrew Cooper <andrew.cooper3@...rix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	Kees Cook <keescook@...omium.org>,
	David Vrabel <david.vrabel@...rix.com>
Subject: Re: [Xen-devel] [PATCH] Solved the Xen PV/KASLR riddle

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

> 
> ~Andrew
> 



Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)