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

RE: [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


 


Rackspace

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