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: <510AADBE02000078000BB190@nat28.tlf.novell.com>
Date:	Thu, 31 Jan 2013 16:45:34 +0000
From:	"Jan Beulich" <JBeulich@...e.com>
To:	"KY Srinivasan" <kys@...rosoft.com>
Cc:	"olaf@...fle.de" <olaf@...fle.de>, "bp@...en8.de" <bp@...en8.de>,
	"apw@...onical.com" <apw@...onical.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"jasowang@...hat.com" <jasowang@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"hpa@...or.com" <hpa@...or.com>
Subject: RE: [PATCH 2/3] X86: Add a check to catch Xen emulation of
 Hyper-V

>>> On 31.01.13 at 16:53, KY Srinivasan <kys@...rosoft.com> wrote:
> Are there any published standards in terms of how the CPUID space should be 
> populated in the range from 0x40000000 to 0x40010000. Specifically, unless 

I recall having seen this range being marked as reserved for
hypervisor use somewhere, but I don't remember where that was.

> the standard mandates that all ranges unused by a given hypervisor would 
> return a known value, how can this code be used to detect the presence of an 
> unknown hypervisor. Hyper-V is going to return the Hyper-V string at 
> 0x40000000. So, I was planning to scan starting at 0x40000100. Clearly, I can 
> check for a specific hypervisor that I know causes a problem for Hyper-V (as I 
> have currently done by checking for Xen). How can I check for the presence of 
> yet to be created Hypervisors that may emulate Hyper-V by scanning the CPUID 
> space. I am almost tempted to say that Xen is the special case and the patch 
> I have submitted addresses that. If a new (or existing hypervisor) plans to 
> do what Xen is doing, perhaps we can dissuade them from doing that or we can 
> fix that within the general framework we have here.

I'd simply preset ECX, EDX, and EBX to zero, and check whether
they change on any EAX input divisible by 256, skipping the one
range you know Hyper-V sits in.

Jan

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ