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

RE: [Xen-devel] EFER in HVM guests

To: "Jan Beulich" <jbeulich@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Keir Fraser" <keir@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] EFER in HVM guests
From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Wed, 29 Nov 2006 15:22:13 +0100
Delivery-date: Wed, 29 Nov 2006 07:38:17 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <456DA265.76E4.0078.0@xxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AccTv7UVEKSpgkiTS/+6n+kFto/vVAAAJEDg
Thread-topic: [Xen-devel] EFER in HVM guests
 

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Jan Beulich
> Sent: 29 November 2006 14:08
> To: xen-devel@xxxxxxxxxxxxxxxxxxx; Keir Fraser
> Subject: Re: [Xen-devel] EFER in HVM guests
> 
> >>> Keir Fraser <keir@xxxxxxxxxxxxx> 29.11.06 14:09 >>>
> >On 29/11/06 13:07, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
> >
> >> Is it intentional that
> >> - under SVM, 32-bit guests can freely set EFER.LME
> >> - under VMX, 32-bit guests can't access EFER at all?
> >> 
> >> Thanks, Jan
> >
> >I'm sure any differences are unintentional. There is 
> obviously scope for
> >making much of the MSR and CPUID code non-vmx/svm specific.
> >
> >I assume that this particular difference doesn't really matter?
> 
> I think it does - allowing a guest to enable EFER.LME when the
> hypervisor is a 32-bit one is clearly a security problem: While I
> haven't tried it, I would suspect the moment you load a context
> with such an EFER the whole system's dead.

Actually, it's a bit more complex than that, but assuming the guest has
access to EFER, it also has access to CR0, so it could try to enable
long mode by:
CR0.PG = 0
CR4.PAE = 1
EFER.LME = 1
CR0.PG = 1

If PAE isn't available, it wouldn't be possible to set long-mode
(processor consistency checks for PAE=1 when LME=1). See section 14.6.3
in the AMD Programmers Manual Vol 2. 

I think that the setting of EFER.LME in 32-bit Hypervisor should
generate GP-fault, as that's what the real processor does... 

> Not being able to access EFER is also a potential problem, as a
> guest should be allowed to set EFER.NX (at least) - the CPUID
> handling code specifically does not suppress this bit if the guest
> is allowed to use PAE (which we agreed a few days ago should
> be the default anyway).

This makes sense to me. As well as EFER.SCE, perhaps?

--
Mats
> 
> Jan
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel