Linux Virtualization - Oct 2014 - [Xen-devel] [RFC] Hypervisor RNG and enumeration

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.

On 29/10/14 05:19, Andy Lutomirski wrote:
> 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?
As a first pass, it looks like a plausible idea.  I do however have come
comments.
>
> 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.
While testing various nested combinations, XenServer has found that
modern Windows Server versions must have the hypervisor bit hidden from
them for them to be happy running HyperV, despite the fact that they
will make use of the Viridian virtual extensions also provided.

As a result, while it is certainly advisable for the hypervisor bit to
be set, CommonHV should be available to be found by paravirtualised
drivers inside an OS which can't cope with the hypervisor bit set.
>
> 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.
How do you evaluate N?

It would make more sense for CPUID.4F000001[ECX=0] to return N in one
register, and perhaps "prefered interface index" in another.  The
signatures can then be obtained from CPUID.4F000001[ECX={1 to N}].

That way, a consumer can be confident that they have found all the
signatures, without relying on an unbounded loop and checking for zeroes.
>
> 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.
This doesn't match the name of "miscellaneous features". 
Furthermore, 0
is a valid (albeit unlikely) MSR index.

How about having a proper bitmask, where bit 0 in one of the registers
means "the RNG information at leaf 4F000003 is valid"?
>
> ### 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.
Is it useful for the hypervisor to inform the guest (perhaps by a
bitfield in 4F000003) whether the number is cryptographically secure or
not?  I am not sure, as at the end of the day the guest will have to
completely trust the hypervisor, but it might be useful to signify "this
number is most certainly not cryptographically secure".

Xen itself has no entropy pool, so is certainly not in a position to
provide a cryptographically secure number.
>
> 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).
This is in contradiction to the previous paragraph.  If the hypervisor
is not capable of providing random numbers, it should not advertise the
presence of 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).
Under what circumstances might this be useful.  The hypervisor cannot
possibly trust that the numbers are even random at all, meaning that the
only safe action is to completely discard them.

Furthermore, the hypervisor itself is in a much better position to draw
entropy from other places in the system, and virtual machines are
specifically lacking in good sources of entropy.  No VM should be
exhausting its limited entropy by trying to push random numbers back at
the hypervisor.

~Andrew
>
> 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 at lists.xen.org
> http://lists.xen.org/xen-devel

On 10/29/2014 11:37 AM, Andrew Cooper wrote:
> While testing various nested combinations, XenServer has found that
> modern Windows Server versions must have the hypervisor bit hidden from
> them for them to be happy running HyperV, despite the fact that they
> will make use of the Viridian virtual extensions also provided.
Right.
> As a result, while it is certainly advisable for the hypervisor bit to
> be set, CommonHV should be available to be found by paravirtualised
> drivers inside an OS which can't cope with the hypervisor bit set.
Microsoft should just stop putting arbitrary limitations on their
software; or pay the price which, in this case, is not being able to use
the features from the common specification.  I guess what they'd do is
reinvent the RNG as a Viridian extension (if they need it).

You can certainly do CPUID(0x4F000000) even if HYPERVISOR=0.  What you
get back is undefined, but in all likelihood it won't be the
"CommonHVIntf" string.

Paolo

Andy Lutomirski writes ("[Xen-devel] [RFC] Hypervisor RNG and
enumeration"):
> Here's a draft CommonHV spec.  It's also on github:
> https://github.com/amluto/CommonHV
This a worthwhile direction to investigate, and an interesting
proposal.  From a Xen point of view I have some concerns, though.

I think in Xen we would want to implement the bulk of the provision of
random numbers to guests outside the hypervisor.  That is, the
hypervisor itself should not have random number pool code, associated
policy, and so on.  We would like to avoid adding too much code to the
hypervisor.

That functionality should live in the lower toolstack layers.  For the
benefit of people who want to do radical disaggregation (for security
reasons), it should be capable of being provided by a different domain
to dom0.

I think a fully general interface based purely on MSRs makes that
difficult in a number of ways:

 * Currently I don't think there is any way in Xen to cause MSR
   accesses to be passed to toolstack support programs.

 * In some configurations, Xen PV domains do not have a suitable
   longrunning service process to handle requests of this kind.

 * MSR reads of this kind might be expected to be fast but if they
   involve trapping to a service domain they might be very slow.

 * This interface is very x86-specific.


It seems to me that the real need for this facility is to provide a
good seed for the guest's own cryptographic PRNG.  If we restrict
ourselves to that use case, we can sidestep the difficulties.

In particular, the parts of this proposal that are most difficult are:

 * The facility for the guest to provide random numbers back to the
   host.  I think this can be dealt with easily by hypervisor-specific
   mechanisms, if it is desirable.

 * The implication that a hypervisor ought to be providing a unbounded
   stream of random numbers, rather than a fixed amount of seed.


I think the most obvious approach would be to provide the VM, at
startup, with a page containing a fixed amount of random number seed,
along with some metatdata.

Some platform-specific way of discovering the location of the page
would have to be defined.  (That might an MSR but more likely it would
be Device Tree or ACPI.)

After the guest has read the page, it would be free to treat it as
normal memory.

The metadata need do little more than specify the length and the
amount of provided entropy.  There should be some room for expansion.

The specification should say that the provided seed MUST be
cryptographically secure, MUST have as much entropy as stated and that
that amount of entropy MUST be at least (say) 64 bits and SHOULD be at
least (say) 256 bits.

Ian.

On 10/29/2014 03:37 AM, Andrew Cooper wrote:
>>
>> 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.
> 
> How do you evaluate N?
> 
> It would make more sense for CPUID.4F000001[ECX=0] to return N in one
> register, and perhaps "prefered interface index" in another.  The
> signatures can then be obtained from CPUID.4F000001[ECX={1 to N}].
> 
> That way, a consumer can be confident that they have found all the
> signatures, without relying on an unbounded loop and checking for zeroes
Yes.  Specifically, it should return it in EAX.  That is the preferred
interface and we are trying to push for that going forward.

	-hpa

On 10/29/2014 03:37 AM, Andrew Cooper wrote:
>>
>> 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.
> 
> How do you evaluate N?
> 
> It would make more sense for CPUID.4F000001[ECX=0] to return N in one
> register, and perhaps "prefered interface index" in another.  The
> signatures can then be obtained from CPUID.4F000001[ECX={1 to N}].
> 
> That way, a consumer can be confident that they have found all the
> signatures, without relying on an unbounded loop and checking for zeroes
Yes.  Specifically, it should return it in EAX.  That is the preferred
interface and we are trying to push for that going forward.

	-hpa

On 10/29/2014 03:37 AM, Andrew Cooper wrote:
>>
>> 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.
> 
> How do you evaluate N?
> 
> It would make more sense for CPUID.4F000001[ECX=0] to return N in one
> register, and perhaps "prefered interface index" in another.  The
> signatures can then be obtained from CPUID.4F000001[ECX={1 to N}].
> 
> That way, a consumer can be confident that they have found all the
> signatures, without relying on an unbounded loop and checking for zeroes
Yes.  Specifically, it should return it in EAX.  That is the preferred
interface and we are trying to push for that going forward.

	-hpa

On Oct 29, 2014 8:17 AM, "Ian Jackson" <Ian.Jackson at
eu.citrix.com> wrote:
>
> Andy Lutomirski writes ("[Xen-devel] [RFC] Hypervisor RNG and
enumeration"):
> > Here's a draft CommonHV spec.  It's also on github:
> > https://github.com/amluto/CommonHV
>
> This a worthwhile direction to investigate, and an interesting
> proposal.  From a Xen point of view I have some concerns, though.
>
> I think in Xen we would want to implement the bulk of the provision of
> random numbers to guests outside the hypervisor.  That is, the
> hypervisor itself should not have random number pool code, associated
> policy, and so on.  We would like to avoid adding too much code to the
> hypervisor.
>
> That functionality should live in the lower toolstack layers.  For the
> benefit of people who want to do radical disaggregation (for security
> reasons), it should be capable of being provided by a different domain
> to dom0.
>
> I think a fully general interface based purely on MSRs makes that
> difficult in a number of ways:
>
>  * Currently I don't think there is any way in Xen to cause MSR
>    accesses to be passed to toolstack support programs.
>
>  * In some configurations, Xen PV domains do not have a suitable
>    longrunning service process to handle requests of this kind.
>
>  * MSR reads of this kind might be expected to be fast but if they
>    involve trapping to a service domain they might be very slow.
I have no objection to specifying that these reads may be quite slow.
Guests should only use them at boot and if they have some reason to
distrust their RNG pool.

The latter can legitimately happen after various types of suspend or
after migration (detected by VM Generation ID, for example).
>
>  * This interface is very x86-specific.
>
Agreed.

Part of the motivation is to allow guests to use this mechanism very
early in boot for stack canaries, ASLR, etc.  I don't know a good way
to do that without something very platform specific.
>
> It seems to me that the real need for this facility is to provide a
> good seed for the guest's own cryptographic PRNG.  If we restrict
> ourselves to that use case, we can sidestep the difficulties.
>
> In particular, the parts of this proposal that are most difficult are:
>
>  * The facility for the guest to provide random numbers back to the
>    host.  I think this can be dealt with easily by hypervisor-specific
>    mechanisms, if it is desirable.
Xen can implement this is a no-op.  If we use feature bits, wrmsr
support could be separately enumerated.
>
>  * The implication that a hypervisor ought to be providing a unbounded
>    stream of random numbers, rather than a fixed amount of seed.
>
I don't expect hypervisors to estimate the entropy available through
this mechanism.  Given that, the length of the stream is largely
irrelevant, except that an unbounded stream allowed reseeding after
boot.
>
> I think the most obvious approach would be to provide the VM, at
> startup, with a page containing a fixed amount of random number seed,
> along with some metatdata.
>
> Some platform-specific way of discovering the location of the page
> would have to be defined.  (That might an MSR but more likely it would
> be Device Tree or ACPI.)
>
> After the guest has read the page, it would be free to treat it as
> normal memory.
>
> The metadata need do little more than specify the length and the
> amount of provided entropy.  There should be some room for expansion.
ACPI is not useful early in boot.  DT might be, but that could be a
separate spec.
>
> The specification should say that the provided seed MUST be
> cryptographically secure, MUST have as much entropy as stated and that
> that amount of entropy MUST be at least (say) 64 bits and SHOULD be at
> least (say) 256 bits.
I don't think this is practical.  It will require hypervisors to
throttle guest startup to ensure that they have that much entropy.

I'm not fundamentally opposed to allowing hypervisors to provide more
than 64 bits of data per invocation, which would help when the trap is
very slow, but I don't know of a suitably simple way to do that.

--Andy

On 29/10/14 05:19, Andy Lutomirski wrote:
> CPUID leaf 4F000002H: miscellaneous features
> --------------------------------------------
> 
[...]
> ### 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).
I would add:

  If the hypervisor's pool of random data is exhausted, it MAY
  return 0.  The hypervisor MUST provide at least 4 (?) non-zero
  numbers to each guest.

Xen does not have a continual source of entropy and the only feasible
way is for the toolstack to provide each guest with a fixed size pool of
random data during guest creation.

The fixed size pool could be refilled by the guest if further random
data is needed (e.g., before an in-guest kexec).
> 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).
I don't think unprivileged guests should be able to influence the
hypervisor's RNG. Unless the intention here is it only affects the
numbers returned to this guest?

But since the write is optional, I don't object to it.

David

On 10/30/2014 01:21 PM, David Vrabel wrote:
> I would add:
> 
>   If the hypervisor's pool of random data is exhausted, it MAY
>   return 0.  The hypervisor MUST provide at least 4 (?) non-zero
>   numbers to each guest.
Mandating "non-zero numbers" sounds like a bad idea.  Just use the RNG
for what it was designed; returning non-random numbers will not be a
problem.

Paolo

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

On Thu, Oct 30, 2014 at 5:21 AM, David Vrabel <david.vrabel at citrix.com>
wrote:
> On 29/10/14 05:19, Andy Lutomirski wrote:
>> CPUID leaf 4F000002H: miscellaneous features
>> --------------------------------------------
>>
> [...]
>> ### 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).
>
> I would add:
>
>   If the hypervisor's pool of random data is exhausted, it MAY
>   return 0.  The hypervisor MUST provide at least 4 (?) non-zero
>   numbers to each guest.
>
> Xen does not have a continual source of entropy and the only feasible
> way is for the toolstack to provide each guest with a fixed size pool of
> random data during guest creation.
>
Xen could seed a very simple per-guest DRBG at guest startup and then
let the rdmsr call read from it.
> The fixed size pool could be refilled by the guest if further random
> data is needed (e.g., before an in-guest kexec).
That gets complicated.  Then you need an API to refill it.
>
>> 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).
>
> I don't think unprivileged guests should be able to influence the
> hypervisor's RNG. Unless the intention here is it only affects the
> numbers returned to this guest?
>
An RNG can be designed to be secure even if malicious users can
provide input.  Linux has one of these, and I assume that Windows
does, too.  Xen doesn't for the entirely legitimate reason that Xen
has no need for such a thing.  (Xen dom0, on the other hand, has
Linux's.)
> But since the write is optional, I don't object to it.
Draft 2 has a bit that Xen could clear to ask the guest not to even
try to use this feature.

I'll send out draft 2 by email later today.  It's on github now, though.

--Andy