Re: [Xen-devel] [RFC] x86: PV SMAP for 64-bit guests

[David Vrabel <david.vrabel@xxxxxxxxxx>]

On 29/01/14 15:33, Jan Beulich wrote:
> Considering that SMAP (and SMEP) aren't usable for 64-bit PV guests
> (due to them running in ring 3), I drafted a mostly equivalent PV
> solution, at this point mainly to see what people think how useful this
> would be.
> 
> It being based on switching page tables (along with the two page
> tables we have right now - one containing user mappings only, the
> other containing both kernel and user mappings - a third category
> gets added containing kernel mappings only; Linux would have such
> a thing readily available and hence presumably would require not
> too intrusive changes) of course makes clear that this would come
> with quite a bit of a performance cost. Furthermore the state
> management obviously requires a couple of extra instructions to be
> added into reasonably hot hypervisor code paths.
> 
> Hence before going further with this approach (for now I only got
> it to the point that an un-patched Linux is unaffected, i.e. I didn't
> code up the Linux side yet) I would be interested to hear people's
> opinions on whether the performance cost is worth it, or whether
> instead we should consider PVH the one and only route towards
> gaining that extra level of security.

If I'm understanding this correctly, in upstream Linux this would
require two new pv-ops for clac and stac?  This might make upstreaming
support for this in Linux tricky, but I wouldn't suggest blocking a Xen
feature for this reason.

Each copy_from_user() and copy_to_user() and get_user()/put_user() would
thus require two hypercalls, at least one of which would do a TLB flush?

This does sound rather expensive and thus not something we (XenServer)
would be especially interested in using.

Do you have any figures for the performance impact on guests not using
this feature?

David

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