Re: [PATCH v2] Enable SMEP CPU feature support for XEN hypervisor

[Keir Fraser <keir.xen@gmail.com>]

On 05/06/2011 16:43, "Li, Xin" <xin.li@intel.com> wrote:

>>> That needs
>>> 1) inject SMEP faults back to the 32-bit pv guest.
>>> 2) let the guest see SMEP thru CPUID and config it in CR4 (actually it's
>>> already set, but just to let guest see it).
>>> 
>>> Anything else?
>> 
>> I thought about this myself and realised that we can't let PV guests control
>> this feature if we want Xen to benefit from it. There's little point in a
>> feature to protect Xen from guests, if an untrusted guest can turn it off!
>> 
>> Hence I think we probably have to leave the feature always on for PV guests.
>> Unless we find some guests are incompatible with that.
> 
> As we talked, 64-bit pv kernel can't trigger SMEP faults. So we decided to not
> let it see this feature.

Yes, we're talking about 32b guests here.

> Maybe it's okay to inject SMEP faults which are triggered from 32-bit pv
> kernel back to it even the guest is not aware of SMEP.

We don't really have a choice about it, if SMEP is enabled. We don't usually
call spurious_page_fault() for guest faults. And as I said, we can't allow a
32b PV guest to disable SMEP, as SMEP is protecting Xen too.

> We can refer to Linux SMEP patch, which just turns this feature on without
> touching any page table handling functions as SMEP handling actually can
> reuse NX handling code path.

Yeah, most likely we can turn this on for PV guests, without them really
knowing about it, and nothing will break.

> Ingo wanted to expose SMEP to KVM guest
> silently, but it is not architecturally right as it's required to flush TLB
> when
> CR4.SMEP is changed, or a kernel page is changed to user page. But luckily
> Linux doesn't have such cases thus doesn't need to flush TLB.

HVM guests are a separate matter and we will want to make SMEP properly
configurable by the guest, as I believe your current patch proposes.

 -- Keir

> Thanks!
> -Xin