Re: [Xen-devel] Ping: [PATCH v3 2/4] x86: suppress SMEP and SMAP while running 32-bit PV guest code

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Fri, May 13, 2016 at 09:30:23AM -0600, Jan Beulich wrote:
> >>> On 13.05.16 at 17:21, <wei.liu2@xxxxxxxxxx> wrote:
> > On Tue, May 03, 2016 at 07:58:58AM -0600, Jan Beulich wrote:
> >> >>> On 17.03.16 at 09:03,  wrote:
> >> > Since such guests' kernel code runs in ring 1, their memory accesses,
> >> > at the paging layer, are supervisor mode ones, and hence subject to
> >> > SMAP/SMEP checks. Such guests cannot be expected to be aware of those
> >> > two features though (and so far we also don't expose the respective
> >> > feature flags), and hence may suffer page faults they cannot deal with.
> >> > 
> >> > While the placement of the re-enabling slightly weakens the intended
> >> > protection, it was selected such that 64-bit paths would remain
> >> > unaffected where possible. At the expense of a further performance hit
> >> > the re-enabling could be put right next to the CLACs.
> >> > 
> >> > Note that this introduces a number of extra TLB flushes - CR4.SMEP
> >> > transitioning from 0 to 1 always causes a flush, and it transitioning
> >> > from 1 to 0 may also do.
> >> > 
> >> > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> >> 
> >> So I think we need to take some decision here, and I'm afraid
> >> Andrew and I won't be able to settle this between us. He's
> >> validly concerned about the performance impact this got proven
> >> to have (for 32-bit PV guests), yet I continue to think that correct
> >> behavior is more relevant than performance. Hence I think we
> >> should bite the bullet and take the change. For those who value
> >> performance more than security, they can always disable the use
> >> of SMEP and SMAP via command line option.
> >> 
> >> Of course I'm also concerned that Intel, who did introduce the
> >> functional regression in the first place, so far didn't participate at
> >> all in finding an acceptable solution to the problem at hand...
> >> 
> > 
> > So this thread has not produced a conclusion. What do we need to do
> > about this issue?
> 
> Andrew privately agreed to no longer object, but of course
> subject to him doing (another) proper review.
> 
> > Do we have a set of patches that make things behave correctly
> > (regardless of its performance impact)?
> 
> Yes, this one.
> 

OK. I will wait for him to review this series.

Wei.

> Jan
> 

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