|
|
|
|
|
|
|
|
|
|
xen-devel
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
|
|
|
|
|