RE: [Xen-devel] EFER in HVM guests - Petersson, Mats - com.xensource.lists.xen-devel

26 messages in com.xensource.lists.xen-develRE: [Xen-devel] EFER in HVM guests

From	Sent On	Attachments
Jan Beulich	29 Nov 2006 05:06
Keir Fraser	29 Nov 2006 05:09
Petersson, Mats	29 Nov 2006 05:11
Jan Beulich	29 Nov 2006 06:07
Jan Beulich	29 Nov 2006 06:08
Petersson, Mats	29 Nov 2006 06:21
Nakajima, Jun	29 Nov 2006 08:34
Keir Fraser	29 Nov 2006 09:21
Petersson, Mats	29 Nov 2006 09:37
Nakajima, Jun	29 Nov 2006 10:23
Li, Xin B	13 Dec 2006 04:47	.patch
Jan Beulich	13 Dec 2006 05:07
Li, Xin B	13 Dec 2006 06:09
Li, Xin B	13 Dec 2006 06:13
Keir Fraser	13 Dec 2006 06:37
Woller, Thomas	15 Dec 2006 08:04
Li, Xin B	18 Dec 2006 07:10	.patch
Petersson, Mats	18 Dec 2006 07:47
Li, Xin B	18 Dec 2006 22:44	.patch
Li, Xin B	18 Dec 2006 23:03
Li, Xin B	19 Dec 2006 01:12
Petersson, Mats	19 Dec 2006 01:46
Li, Xin B	19 Dec 2006 06:25
Woller, Thomas	19 Dec 2006 12:37	.xls
Li, Xin B	19 Dec 2006 17:27
Petersson, Mats	20 Dec 2006 03:29

Subject:	RE: [Xen-devel] EFER in HVM guests
From:	Petersson, Mats (Mats...@amd.com)
Date:	11/29/2006 06:21:50 AM
List:	com.xensource.lists.xen-devel

-----Original Message----- From: xen-...@lists.xensource.com [mailto:xen-...@lists.xensource.com] On Behalf Of Jan Beulich Sent: 29 November 2006 14:08 To: xen-...@lists.xensource.com; Keir Fraser Subject: Re: [Xen-devel] EFER in HVM guests

Keir Fraser <ke...@xensource.com> 29.11.06 14:09 >>>

On 29/11/06 13:07, "Jan Beulich" <jbeu...@novell.com> 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?

Jan