On 04/04/17 16:39, Tamas K Lengyel wrote:
>
>
> On Tue, Apr 4, 2017 at 9:11 AM, Andrew Cooper
> <andrew.coop...@citrix.com <mailto:andrew.coop...@citrix.com>> wrote:
>
> On 04/04/17 13:14, Razvan Cojocaru wrote:
> > Currently xc_translate_foreign_address only checks for PSE bit
> only on
> > level 2 entries (that's 2 MB pages on x64 and 32-bit with PAE,
> and 4 MB
> > pages on 32-bit). But linux kernel sometimes uses 1 GB pages.
> This patch
> > fixes that, and checks the PSE bit on level 3 entries if the
> guest has 4
> > translation levels (that means 64-bit guests only).
> >
> > Signed-off-by: Cristian-Bogdan Sirb <cs...@bitdefender.com
> <mailto:cs...@bitdefender.com>>
>
> This function is in a rather tragic state. Lucky it isn't used by
> code
> covered by Xen's security statement.
>
> This patch reintroduces XSA-176, and the existing code doesn't
> work for
> 4M superpages, or guests using PSE36. (I might be acutely aware of
> pagetable issues, following c/s
> 4c5d78a10dc89). Furthermore, the map/unmap overhead must be a large
> overhead.
>
>
> Indeed it is, that's why in LibVMI there is actually a cache
> implemented for mapped pages so we throw them away only after they
> have been idle for a while.
>
>
>
> How often is this used by introspection? To properly walk the
> pagetables, you need access to the CPUID information (as well as the
> control register state), and that isn't yet available to the toolstack
> in Xen.
>
>
> Control register state is certainly available.
>
>
>
> I'm wondering whether it might be better to have a way of asking
> Xen to
> perform a virtual to linear translation in the context of a specific
> vcpu. My gut feeling is that it might be quicker than running this
> logic, and is definitely more simple than trying to fix this code
> not to
> have vulnerabilities in it.
>
>
> I don't think it would be necessary. IMHO doing this in Xen wouldn't
> really net us much performance-wise. Furthermore, there are certain
> PTE bits that are OS specific and Xen wouldn't necessary have the
> required information to do the translation properly (ie. present bit
> unset but transition bits used for Windows guests).
Ok. Xen needs to care only about the behaviour of real pointers in
guest context, and whether they raise #PF.
It sounds like the best thing to do is to provide userspace with all
information it needs to actually perform the walk safely, and let the
library apply guest-specific knowledge if it wants.
Off the top of my head, the control information needed is:
Hap/Shadow, hardwares views towards page1gb and pse36, whether EFER.NX
is leaked from Xen, EFER.NX, CR0.{PG,WP},
CR4.{PAE,PSE,PCID,SMEP,SMAP,PKE}, and the PDPTRs for the 32bit PAE case,
because the translation in use isn't necessary the value you would read
by following CR3 in memory.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
