[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |