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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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