linux-kernel - RE: Use CPUID to communicate with the hypervisor.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 29 Sep 2008 13:55:19 -0700
From:	"Nakajima, Jun" <jun.nakajima@...el.com>
To:	"akataria@...are.com" <akataria@...are.com>,
	Gerd Hoffmann <kraxel@...hat.com>
CC:	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	the arch/x86 maintainers <x86@...nel.org>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	"avi@...hat.com" <avi@...hat.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Zach Amsden <zach@...are.com>, Daniel Hecht <dhecht@...are.com>
Subject: RE: Use CPUID to communicate with the hypervisor.

On 9/29/2008 12:38:05 PM, Alok Kataria wrote:
> On Mon, 2008-09-29 at 11:46 -0700, Gerd Hoffmann wrote:
> > Alok Kataria wrote:
> > > Hi Gerd,
> > >
> > > > Shouldn't you check the hypervisor signature here?
> > >
> > > Nope the whole idea of not checking the hypervisor signature is
> > > that we should keep this interface generic.
> >
> > Nice idea.  Problem with that is that approach is that we don't have
> > full control here.  It probably isn't that a hard to have vmware,
> > xen and kvm agree here, given vmware proposes this and for xen+kvm
> > one can send patches.
>
> Yep.
> And please note that this does allow either Xen/KVM to propose a new
> leaf and the rest of the hypervisor players can decide to export that
> leaf or return a zero value.
>

For example, we can set the following ranges so that so that each VMM vender can define and implement features avoiding conflicts:
vmware to define 0x4000001X
xen to define 0x4000002X
kvm to define 0x4000003X
...

The point here is that all the features are generic because we don't make them exclusive. To that end, we don't check the signature. Whatever common features can be found in the above, and each hypervisor can choose to implement what was defined by other hypervisors.

Detection of the feature 0x400000XY is done by:
1.  Get EAX from Leaf 0x4000000000, Hypervisor CPUID information. EAX returns the maximum input value for hypervisor CPUID info.

    If EAX < 0x400000XY, then the feature is not available.

2.  Get EAX from the target Leaf 0x400000XY by doing cpuid_eax(0x400000XY).

    If (EAX == 0), the feature is not implemented.

If the hypervisor does not implement a particular feature specified by 0x400000XN and 0x400000XN < 0x400000XY, the hypervisor needs to return 0 in EAX with cpuid_eax(0x400000XN) (XN > 0).

             .
Jun Nakajima | Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/