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

From: "Wu, Feng" <feng.wu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	xen-devel <xen-devel@lists.xenproject.org>,
	"Wu, Feng" <feng.wu@intel.com>
Subject: Re: Ping: [PATCH v3 2/4] x86: suppress SMEP and SMAP while running 32-bit PV guest code
Date: Wed, 4 May 2016 03:07:11 +0000	[thread overview]
Message-ID: <E959C4978C3B6342920538CF579893F00C3E69E1@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <5728CAC202000078000E80D8@prv-mh.provo.novell.com>

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Tuesday, May 3, 2016 9:59 PM
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>; Wei Liu
> <wei.liu2@citrix.com>; George Dunlap <George.Dunlap@eu.citrix.com>; Ian
> Jackson <Ian.Jackson@eu.citrix.com>; Wu, Feng <feng.wu@intel.com>; Stefano
> Stabellini <sstabellini@kernel.org>; xen-devel <xen-devel@lists.xenproject.org>;
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>; Tim Deegan <tim@xen.org>
> Subject: Ping: [PATCH v3 2/4] x86: suppress SMEP and SMAP while running 32-bit
> PV guest code
> 
> >>> 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@suse.com>
> 
> 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.

I think this is a proper solution for those who cares more about
performance. And BTW, Andrew, is there any detailed data which can
show the exact performance overhead introduced by this patch?

Thanks,
Feng

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

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