[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] Libxc: fix xc_translate_foreign_address()



On 04/04/2017 06:11 PM, Andrew Cooper 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 <csirb@xxxxxxxxxxxxxxx>
> 
> 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.
> 
> 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.
> 
> 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.

We have a workaround looking directly into the guest but have felt that
the proper thing to do was to contribute the fix back to Xen.


Thanks,
Razvan

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.