[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: "Li, Xin" <xin.li@xxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
  • From: Keir Fraser <keir.xen@xxxxxxxxx>
  • Date: Sun, 05 Jun 2011 18:04:06 +0100
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Sun, 05 Jun 2011 10:05:31 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=kJcI3JuIqXpHlm6QPfRtWkFZeFNaI0DAFV1VBNZ7khrXdR49ZawdZlRIUnrflP8BEY 8gx7w+iWC5fFhHR0rcgW5RJZVD+AO/08QLRIpLQ8rldwdI8LvHm3BOkjk4u0Y9Y4cJri 4f68A3VMozMTjjc2UW8WiY8wIYW2B7i+ao2WI=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcwjU0w8vlsr1zIxRuCnN1Lck9yOlQAB+c7AAA3egwgAAKz9kAADTJx2
  • Thread-topic: [PATCH v2] Enable SMEP CPU feature support for XEN hypervisor

On 05/06/2011 16:43, "Li, Xin" <xin.li@xxxxxxxxx> 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

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.