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 17:33:22 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Zachary Amsden <zach@...are.com>
CC:	Jeremy Fitzhardinge <jeremy@...p.org>,
	"Nakajima, Jun" <jun.nakajima@...el.com>,
	Alok Kataria <akataria@...are.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>,
	Daniel Hecht <dhecht@...are.com>
Subject: Re: Use CPUID to communicate with the hypervisor.

Zachary Amsden wrote:
> 
> Aren't we overthinking / overdesigning this a bit?  It's not rocke
> science.  We'd like to have a leaf set aside for TSC frequency, and
> maybe another leaf in the future.  We think other vendors might find a
> static clock frequency leaf to be useful, so if that happens to be the
> case, feel free to re-use the leaf.
> 

No, I don't think we are.  Under the circumstances I do not think 
anything other than positive identification is unacceptable.

If anything, the whole concept of reusing interfaces is what

> We don't expect to see lots of proliferation of CPU leaves at all, in
> fact, we'd be flummoxed to propose more than one right now.  So
> basically a nicely written comment section explaining how the SW CPUID
> registers are layed out is probably sufficient.  Other vendors can add
> to it as they see fit, and Linux itself can be the central standard
> body.  After all, it's what we all work on, and it makes sense for
> everyone here, even MS, to have the software leaves defined in a public
> work.

NIH is a huge factor, and MS is worse than most.

> The whole thing is software defined so it's not a big deal if one or all
> parties eventually don't play well with others, grow up to become
> bullies with ADD, or simply autistic children who ignore the whole
> thing.  You can always make detection vendor dependent when that
> happens.
> 
> Right now there's nothing shockingly vendor dependent, just a whole lot
> of complicated proposals about how to define what the bits are going to
> define and not enough bits of information to actually express.  It seems
> perfectly okay for now to have new leaf proposals defined by fiat for
> now.
> 
> As long as there is a vendor-ID leaf, nobody is blocking any forward
> progress by adding a new non-conflicting leaf.  We can always add the
> meta-leafs required for decoding if something tangible materializes, but
> for now the TSC leaf seems pretty useful and I would probably want to
> proclaim it by fatwa, if I had such a power.

If someone had the power to proclaim it by fatwa we wouldn't have much 
to worry about.  Intel might have the power, but we as a group in this 
thread definitely do not.

However, it is clear the virtualization industry doesn't have their act 
together to the point where one can rely on anything but positive 
identification, unlike in the hardware space, where we can rely on 
implicit identification, because people aren't stepping on each other's 
toes.

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