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

Message-ID: <46EED250.5080207@goop.org>
Date:	Mon, 17 Sep 2007 12:15:28 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	"Nakajima, Jun" <jun.nakajima@...el.com>
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

Nakajima, Jun wrote:
> Using CPUID.0x4000000N (N > 2) does not prevent Xen from doing that,
> either. If you use 0x40001000, 1) you need to say the leaves from
> 0x40000000 through 0x40001000 are all valid, OR 2) you create/fork a
> new/odd leaf (with 0x1000 offset) repeating the detection redundantly. 
>   

I don't see a particular problem with that.  If the whole 0x4xxxxxxx
range is reserved for hypervisor use, and existing hypervisors are
already using 0x400000xx in hypervisor-specific ways, then it makes
sense to start the generic stuff at 0x40001xxx (or some other offset). 
But without a few more implementations of the "generic" interface its
all a bit moot (ie, where's your code? ;).

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

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