From owner-freebsd-virtualization@FreeBSD.ORG Thu Oct 30 14:37:20 2014 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0740DA1 for ; Thu, 30 Oct 2014 14:37:20 +0000 (UTC) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Cybertrust Public SureServer SV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F185230 for ; Thu, 30 Oct 2014 14:37:18 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.07,286,1413244800"; d="scan'208";a="186515465" Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id 14.3.181.6; Thu, 30 Oct 2014 10:33:30 -0400 Message-ID: <54524C36.8050203@citrix.com> Date: Thu, 30 Oct 2014 15:33:26 +0100 From: =?windows-1252?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Andy Lutomirski , Linux Virtualization Subject: Re: [Xen-devel] [RFC] Hypervisor RNG and enumeration References: In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-DLP: MIA2 X-Mailman-Approved-At: Thu, 30 Oct 2014 18:30:07 +0000 Cc: Mathew John , Theodore Ts'o , Jim Mattson , kvm list , Gleb Natapov , Niels Ferguson , David Hepkin , Doug Covelli , freebsd-virtualization@freebsd.org, Paolo Bonzini , Christopher Covington , Jun Nakajima , "H. Peter Anvin" , Jake Oshins , xen-devel@lists.xenproject.org, Alok Kataria , KY Srinivasan , John Starks X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 14:37:20 -0000 Adding the bhyve guys. El 29/10/14 a les 6.19, Andy Lutomirski ha escrit: > Here's a draft CommonHV spec. It's also on github: > > https://github.com/amluto/CommonHV > > So far, this provides a two-way RNG interface, a way to detect it, and > a way to detect other hypervisor leaves. The latter is because, after > both the enormous public thread and some private discussions, it seems > that detection of existing CPUID paravirt leaves is annoying and > inefficient. If we're going to define some cross-vendor CPUID leaves, > it seems like it would be useful to offer a way to quickly enumerate > other leaves. > > I've been told the AMD intends to update their manual to match Intel's > so that hypervisors can use the entire 0x4F?????? CPUID range. I have > intentionally not fixed an MSR value for the RNG because the range of > allowed MSRs is very small in both the Intel and AMD manuals. If any > given hypervisor wants to ignore that small range and advertise a > higher-numbered MSR, it is welcome to, but I don't want to codify > something that doesn't comply with the manuals. > > Here's the draft. Comments? To the people who work on various > hypervisors: Would you implement this? Do you like it? Is there > anything, major or minor, that you'd like to see changed? Do you > think that this is a good idea at all? > > I've tried to get good coverage of various hypervisors. There are > Hyper-V, VMWare, KVM, and Xen people on the cc list. > > Thanks, > Andy > > > > CommonHV, a common hypervisor interface > ======================================= > > This is CommonHV draft 1. > > The CommonHV specification is Copyright (c) 2014 Andrew Lutomirski. > > Licensing will be determined soon. The license is expected to be extremely > liberal. I am currently leaning towards CC-BY-SA for the specification and > an explicit license permitting anyone to implement the specification > with no restrictions whatsoever. > > I have not patented, nor do I intend to patent, anything required to implement > this specification. I am not aware of any current or future intellectual > property rights that would prevent a royalty-free implementation of > this specification. > > I would like to find a stable, neutral steward of this specification > going forward. Help with this would be much appreciated. > > Scope > ----- > > CommonHV is a simple interface for communication > between hypervisors and their guests. > > CommonHV is intended to be very simple and to avoid interfering with > existing paravirtual interfaces. To that end, its scope is limited. > CommonHV does only two types of things: > > * It provides a way to enumerate other paravirtual interfaces. > * It provides a small, extensible set of paravirtual features that do not > modify or replace standard system functionality. > > For example, CommonHV does not and will not define anything related to > interrupt handling or virtual CPU management. > > For now, CommonHV is only applicable to the x86 platform. > > Discovery > --------- > > A CommonHV hypervisor MUST set the hypervisor bit (bit 31 in CPUID.1H.0H.ECX) > and provide the CPUID leaf 4F000000H, containing: > > * CPUID.4F000000H.0H.EAX = max_commonhv_leaf > * CPUID.4F000000H.0H.EBX = 0x6D6D6F43 > * CPUID.4F000000H.0H.ECX = 0x56486E6F > * CPUID.4F000000H.0H.EDX = 0x66746e49 > > EBX, ECX, and EDX form the string "CommonHVIntf" in little-endian ASCII. > > max_commonhv_leaf MUST be a number between 0x4F000000 and 0x4FFFFFFF. It > indicates the largest leaf defined in this specification that is provided. > Any leaves described in this specification with EAX values that exceed > max_commonhv_leaf MUST be handled by guests as though they contain > all zeros. > > CPUID leaf 4F000001H: hypervisor interface enumeration > ------------------------------------------------------ > > If max_commonhv_leaf >= 0x4F000001, CommonHV provides a list of tuples > (location, signature). Each tuple indicates the presence of another > paravirtual interface identified by the signature at the indicated > CPUID location. It is expected that CPUID.location.0H will have > (EBX, ECX, EDX) == signature, although whether this is required > is left to the specification associated with the given signature. > > If the list contains N tuples, then, for each 0 <= i < N: > > * CPUID.4F000001H.i.EBX, CPUID.4F000001H.i.ECX, and CPUID.4F000001H.i.EDX > are the signature. > * CPUID.4F000001H.i.EAX is the location. > > CPUID with EAX = 0x4F000001 and ECX >= N MUST return all zeros. > > To the extent that the hypervisor prefers a given interface, it should > specify that interface earlier in the list. For example, KVM might place > its "KVMKVMKVM" signature first in the list to indicate that it should be > used by guests in preference to other supported interfaces. Other hypervisors > would likely use a different order. > > The exact semantics of the ordering of the list is beyond the scope of > this specification. > > CPUID leaf 4F000002H: miscellaneous features > -------------------------------------------- > > CPUID.4F000002H.EAX is nonzero if the CommonHV RNG interface is available. > CPUID.4F000002H.EBX, CPUID.4F000002H.ECX, and CPUID.4F000002H.EDX are reserved > and must be zero in hypervisors compliant with this version of the CommonHV > specification. > > ### CommonHV RNG > > If CPUID.4F000002H.EAX is nonzero, then it contains an MSR index used to > communicate with a hypervisor random number generator. This MSR is > referred to as MSR_COMMONHV_RNG. > > rdmsr(MSR_COMMONHV_RNG) returns a 64-bit best-effort random number. If the > hypervisor is able to generate a 64-bit cryptographically secure random number, > it SHOULD return it. If not, then the hypervisor SHOULD do its best to return > a random number suitable for seeding a cryptographic RNG. > > A guest is expected to read MSR_COMMONHV_RNG several times in a row. > The hypervisor SHOULD return different values each time. > > rdmsr(MSR_COMMONHV_RNG) MUST NOT result in an exception, but guests MUST > NOT assume that its return value is indeed secure. For example, a hypervisor > is free to return zero in response to rdmsr(MSR_COMMONHV_RNG). > > wrmsr(MSR_COMMONHV_RNG) offers the hypervisor up to 64 bits of entropy. > The hypervisor MAY use it as it sees fit to improve its own random number > generator. A hypervisor SHOULD make a reasonable effort to avoid making > values written to MSR_COMMONHV_RNG visible to untrusted parties, but > guests SHOULD NOT write sensitive values to wrmsr(MSR_COMMONHV_RNG). > > A hypervisor is free to ignore wrmsr(MSR_COMMONHV_RNG), but wrmsr to > MSR_COMMONHV_RNG MUST NOT result in an exception. > > Note that the CommonHV RNG is not intended to replace stronger, asynchronous > paravirtual random number generator interfaces. It is intended primarily > for seeding guest RNGs early in boot. > > Future extension > ---------------- > > CPUID leaves beyond those defined in this version of the CommonHV specification > should be ignored by guests written for this version of the specification. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >