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

[Andrew Cooper <andrew.cooper3@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.

In principle, I think this is a good idea.  We certainly should provide
any opportunity we can to aid the security of the VMs.

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

This appears to be hardware independent, so looks as if it would still
work fine on 64bit hardware lacking explicit SMAP/SMEP support?
(although possibly problems with emulating {ST,CL}AC)

>
> 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.
>
> And if considering it worthwhile, comments on the actual
> implementation (including the notes at the top of the attached
> patch) would of course be welcome too.
>
> Jan


At a glance, it doesn't appear to add too much code to hot-paths, but
the performance overhead from the point of view of the PV guest looks
substantial, requiring two hypercalls/traps on each
copy_{to,from}_user(), which themselves cause a local TLB flush.

~Andrew

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