From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: EFER in HVM guests Date: Wed, 29 Nov 2006 14:08:21 +0000 Message-ID: <456DA265.76E4.0078.0@novell.com> References: <456D940A.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com, Keir Fraser List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 29.11.06 14:09 >>> >On 29/11/06 13:07, "Jan Beulich" 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. 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). Jan