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]

Message-Id: <1222733523.30247.91.camel@alok-dev1>
Date:	Mon, 29 Sep 2008 17:12:03 -0700
From:	Alok Kataria <akataria@...are.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	"Nakajima, Jun" <jun.nakajima@...el.com>,
	Gerd Hoffmann <kraxel@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	the arch/x86 maintainers <x86@...nel.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 Mon, 2008-09-29 at 14:28 -0700, Jeremy Fitzhardinge wrote:
> H. Peter Anvin wrote:
> > Nakajima, Jun wrote:
> >>
> >> 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
> >> ...
> >>
> >
> > Unless there is a central authority assigning these, "we" can do all
> > we want, enough people will not pay attention.
> >
> > Basically, there needs to be a standards document that describes the
> > architecture, *and* needs to either have universal buy-in with all the
> > vendors or imposed by an authority with enough clout to do so (Intel
> > might.)
> 
> I think using fixed offsets is unwise, since there's already contention
> for the same leaves. 

Sure, some leaves have been defined already, but it's not too late to
try to go the generic route for the remaining leaves.
The longer we wait to come to a consensus on generic leaves, the more
contention we will have.  So let's try to address it now.  

>  Making sure that each block of leaves (where a
> block is 16, 256 or some other number of leaves) is self-describing via
> ABI signatures is the only sane way to go.  There's still the issue of
> assigning ABI signatures to vendors, but that's 1) less of an issue, and
> 2) can be self-assigned with very low likelihood of collision.  That way
> a guest can scan that region of leaf space for ABI signatures it
> understand, and can pick and choose among what it finds (but not mix and
> match - that sounds like a course for disaster).
> 
> If we use such a scheme, we can 1) avoid any existing users of that
> space, 2) cleanly delimit a hypervisor-agnostic ABI portion of the leaf
> space, and 3) allow hypervisors to implement multiple ABIs at once.

I don't agree that this solution makes any difference OTOH, it just
complicates the situation.
Here is why....

1. This solution really bloats the kernel, below are few observations

i)  What happens if two ABI signature blocks define a cpuid leaf which
have similar semantics, how does the kernel handle this ?
ii) Also, think about a case where a hypervisor supports 2 such ABI
blocks - which have cpuid leafs with similar semantics - and decides to
implement one of those and not the other leaf. How does the kernel
handle this ?

I do understand that there are ways to handle this in the kernel but at
the cost of just making the kernel more and more complicated for such
corner cases.

2. Also as a side note, what you are proposing just breaks down the
problem in to sub-problems, i.e we still need to make sure that the
individual cpuid leafs in the "block of leaves" are still generic. Also
we may still have situations where hypervisor "A" wants to define a
subset of cpuid block X, hypervisor B had defined.

3. All in all, the end result of doing this would be that each
hypervisor defines its own signature block forgetting about what the
other hypervisor is doing. This is hardly generalizing this space.

Seriously, if we want to generalize this in the current situation, how
about doing this ? 

1. Have 0x40000000 as the hypervisor signature leaf.
2. Have 0x40000001-0x4000000F as the hypervisor specific leafs.
3. 0x40000010 - 0x400000FF as the generic space. 
Use the non-zero meaning defined semantics for this generic space. 

Thanks,
Alok

> 
>     J

--
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/