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: <48E17363.7060103@zytor.com>
Date:	Mon, 29 Sep 2008 17:31:31 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	akataria@...are.com
CC:	Jeremy Fitzhardinge <jeremy@...p.org>,
	"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.

Alok Kataria wrote:
> 
> 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.  
> 

We don't have a quorum to create a consensus, since we only have a 
subset of the relevant parties present.

We can get away with that if we agree on a standard that includes 
postive definition.

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

You have no basis for that assertion.

> i)  What happens if two ABI signature blocks define a cpuid leaf which
> have similar semantics, how does the kernel handle this ?

We already have this situation in a number of places.  The answer is 
generally that there is one form that the kernel prefer over another (in 
CPUID space, leaf 80000006 over leaf 2, for example) because it is 
better designed/more reliable/mode complete.

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

The standard way to handle that in CPUID space is to leave the 
unimplemented leaf as zero.

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

The complexity is relatively minor.

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

It gives individual sub-APIs positive identification.  This is similar 
to PCI capabilities, for example.

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

As I said, I don't think we have any kind of quorum to declare such a 
"standard", and we'll see violations with failures as a result.

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