linux-kernel - RE: [kvm-devel] [PATCH] Refactor hypercall infrastructure

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] [day] [month] [year] [list]

Date:	Mon, 17 Sep 2007 13:52:25 -0700
From:	"Nakajima, Jun" <jun.nakajima@...el.com>
To:	"Jeremy Fitzhardinge" <jeremy@...p.org>
Cc:	"Anthony Liguori" <aliguori@...ibm.com>,
	<kvm-devel@...ts.sourceforge.net>, "Avi Kivity" <avi@...ranet.com>,
	<linux-kernel@...r.kernel.org>
Subject: RE: [kvm-devel] [PATCH] Refactor hypercall infrastructure

Jeremy Fitzhardinge wrote:
> Nakajima, Jun wrote:
> 
> > Again, 0x40000000 is not Xen specific. If the leaf 0x40000000 is
used
> > for any guest to detect any hypervisor, that would be compelling
> > benefit. For future Xen-specific features, it's safe for Xen to use
> > other bigger leaves (like 0x40001000) because the guest starts
looking
> > at them after detection of Xen.
> > 
> > Likewise if KVM paravirtualization interface (as kind of "open
source
> > paravirtualization interface") is detected in the generic areas (not
in
> > vender-specific), any guest can check the features available without
> > knowing which hypervisor uses which CPUID for that.
> > 
> 
> This just seems a bit grotty.  You're relying on the fact that you can
> overlay Xen's current use of 0x4000000x for the generic interface by
> freezing Xen's current use of 40000000-2.  0x40000000 becomes a more
or
> less useless hypervisor-identification signature (useless because you
> need to assume that leaves 4000000x, x>2 implement the generic
interface
> anyway, where x=1,2 are reserved for Xen (=hypervisor-specific) uses).

No, really. Xen just _implemented_ the generic interface from the
beginning, at least for 0 and 1 (version). The 0x40000002 (hypercall
page) looks specific to Xen, but it can be used for KVM as well, thus
can be generic (or a hypervisor can tell it's not supported by returning
0 pages for hypercall pages). If Xen implements the new generic feature
(defined by 0x40000003, for example), then it returns 40000003 or large
for the max leaf upon CPUID.0x40000000.

> 
> In other words, what mechanism can a guest use to explicitly identify
> the existence of the generic interface?  There needs to be a signature
> for that somewhere.
> 
>     J
So you don't need a signature for that. 

As I wrote before:
1. detect Xen or KVM <the list> using CPUID.0x40000000 
2. Check the version if necessary using CPUID.0x40000001
3. Check the generic features available using CPUID.0x4000000Y, if the
max leaf returned >= 0x4000000Y.

A guest wants to want to know who the hypervior is for practical
purposes (e.g. debuggging) anyway. This is equivalent to what a native
OS would do to detect a generic CPU feature.

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