Re: [Xen-devel] [RFC] Hypervisor RNG and enumeration

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel