WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Li, Xin" <xin.li@xxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH v2] Enable SMEP CPU feature support for XEN hypervisor
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
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=YvqmaPF5gG7hXo3ZQ5QzUBAjTkflpPL45+Yq6yxtD6o=; b=tGNMgLlHb7sBfvn3HimvWg0eaqY1Oknwf0NW8bTTf20vJWQjBuilnLQ0RqN178R8iW g8buZ7RZTFLPQKgVptJMPisM5v3OE/VoMvPVga5197x2B66W9fKstVorGn9G4gmrLQB/ Jo7zvrCDrTXjgthGOLVd8zlg7/Fk2kscCCN/I=
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=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <FC2FB65B4D919844ADE4BE3C2BB739AD5AB9EE2F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcwjU0w8vlsr1zIxRuCnN1Lck9yOlQAB+c7AAA3egwgAAKz9kAADTJx2
Thread-topic: [PATCH v2] Enable SMEP CPU feature support for XEN hypervisor
User-agent: Microsoft-Entourage/12.29.0.110113
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel