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
| ||
|
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/
Powered by blists - more mailing lists