Re: [Xen-devel] [RFC] Hypervisor RNG and enumeration
On Thu, 2014-10-30 at 07:45 -0700, Andy Lutomirski wrote: > > 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. I think I'm a bit confused by the intended scope of this facility. The original spec said: 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. Which to me reads that the guest should be using this facility to seed it's own simple DRBG on boot (with some finite amount of seed data from the hv) and then using that until it can switch to something better. Is that not the intention? I think it's important to nail down the intended scope of this interface, since it has quite an impact on what would be considered a reasonable common design. Post boot I would as you say expect most OSes to switch over to something more capable, not continue to rely on this facility for the duration. Ian. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] [RFC] Hypervisor RNG and enumeration
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 4F00H, containing: > > * CPUID.4F00H.0H.EAX = max_commonhv_leaf > * CPUID.4F00H.0H.EBX = 0x6D6D6F43 > * CPUID.4F00H.0H.ECX = 0x56486E6F > * CPUID.4F00H.0H.EDX = 0x66746e49 > > EBX, ECX, and EDX form the string "CommonHVIntf" in little-endian ASCII. > > max_commonhv_leaf MUST be a number between 0x4F00 and 0x4FFF. 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 4F01H: hypervisor interface enumeration > -- > > If max_commonhv_leaf >= 0x4F01, 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.4F01H.i.EBX, CPUID.4F01H.i.ECX, and CPUID.4F01H.i.EDX > are the signature. > * CPUID.4F01H.i.EAX is the location. > > CPUID with EAX = 0x4F01 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 >
Re: [Xen-devel] [RFC] Hypervisor RNG and enumeration
On Thu, Oct 30, 2014 at 5:21 AM, David Vrabel wrote: > On 29/10/14 05:19, Andy Lutomirski wrote: >> CPUID leaf 4F02H: miscellaneous features >> >> > [...] >> ### CommonHV RNG >> >> If CPUID.4F02H.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 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] [RFC] Hypervisor RNG and enumeration
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 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] [RFC] Hypervisor RNG and enumeration
On 29/10/14 05:19, Andy Lutomirski wrote: > CPUID leaf 4F02H: miscellaneous features > > [...] > ### CommonHV RNG > > If CPUID.4F02H.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 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] [RFC] Hypervisor RNG and enumeration
On 10/29/2014 05:29 PM, Jake Oshins wrote: > Just as a point of clarification, the VM Generation ID changes (at > least in the Hyper-V implementation) only when the VM may have > observed a different future, as when a VM backup is restored, a > checkpoint is applied, etc. It does not change during migration, > when the VM is suspended or when it is rebooted. I've heard > anecdotes from application vendors saying that there is some other > hypervisor that actually does change the ID at these moments and they > wanted us to us to fix that, until I explained that I only control > Hyper-V. This is indeed the only reasonable way you can read the vmgenid spec. Paolo ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] [RFC] Hypervisor RNG and enumeration
On Wed, Oct 29, 2014 at 9:29 AM, Jake Oshins wrote: > >>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). > > Just as a point of clarification, the VM Generation ID changes (at least in > the Hyper-V implementation) only when the VM may have observed a different > future, as when a VM backup is restored, a checkpoint is applied, etc. It > does not change during migration, when the VM is suspended or when it is > rebooted. I've heard anecdotes from application vendors saying that there is > some other hypervisor that actually does change the ID at these moments and > they wanted us to us to fix that, until I explained that I only control > Hyper-V. > Fair enough. If the VM may indeed have observed a different future, then I would argue that reseeding the RNG is very important -- more so than after a normal migration. If the VM trusts that its other history hasn't been compromised, then merely mixing in a unique value would get most of the benefit. --Andy > -- Jake Oshins > -- Andy Lutomirski AMA Capital Management, LLC ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
RE: [Xen-devel] [RFC] Hypervisor RNG and enumeration
>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). Just as a point of clarification, the VM Generation ID changes (at least in the Hyper-V implementation) only when the VM may have observed a different future, as when a VM backup is restored, a checkpoint is applied, etc. It does not change during migration, when the VM is suspended or when it is rebooted. I've heard anecdotes from application vendors saying that there is some other hypervisor that actually does change the ID at these moments and they wanted us to us to fix that, until I explained that I only control Hyper-V. -- Jake Oshins ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] [RFC] Hypervisor RNG and enumeration
On Wed, Oct 29, 2014 at 9:07 AM, H. Peter Anvin wrote:
> On 10/29/2014 03:37 AM, Andrew Cooper wrote:
>>>
>>> CPUID with EAX = 0x4F01 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.4F01[ECX=0] to return N in one
>> register, and perhaps "prefered interface index" in another. The
>> signatures can then be obtained from CPUID.4F01[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.
>
I'm okay with that.
I'm inclined to leave EBX, ECX, and EDX reserved for now, though.
Barring an actual use case in which the order of the list isn't
sufficient to determine preference, I don't see the need to give
another preference indication.
I updated the copy of github to make this change and to use an
explicit feature bit for the RNG.
--Andy
> -hpa
>
>
--
Andy Lutomirski
AMA Capital Management, LLC
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] [RFC] Hypervisor RNG and enumeration
On Oct 29, 2014 8:17 AM, "Ian Jackson" 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
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] [RFC] Hypervisor RNG and enumeration
On 10/29/2014 03:37 AM, Andrew Cooper wrote:
>>
>> CPUID with EAX = 0x4F01 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.4F01[ECX=0] to return N in one
> register, and perhaps "prefered interface index" in another. The
> signatures can then be obtained from CPUID.4F01[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
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] [RFC] Hypervisor RNG and enumeration
On 10/29/2014 03:37 AM, Andrew Cooper wrote:
>>
>> CPUID with EAX = 0x4F01 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.4F01[ECX=0] to return N in one
> register, and perhaps "prefered interface index" in another. The
> signatures can then be obtained from CPUID.4F01[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
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] [RFC] Hypervisor RNG and enumeration
On 10/29/2014 03:37 AM, Andrew Cooper wrote:
>>
>> CPUID with EAX = 0x4F01 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.4F01[ECX=0] to return N in one
> register, and perhaps "prefered interface index" in another. The
> signatures can then be obtained from CPUID.4F01[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
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] [RFC] Hypervisor RNG and enumeration
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.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] [RFC] Hypervisor RNG and enumeration
On 10/29/2014 02:57 PM, David Vrabel wrote: > Microsoft already has a specification to obtain a random number via an > ACPI device. The VM Generation ID. > > http://www.microsoft.com/en-us/download/details.aspx?id=30707 That's a very different thing. The VM Generation ID always returns the same number if you run the VM from the same configuration file. It tells the VM when it might need a reseed, but provides neither a best effort random number like this spec does, nor an entropy source like virtio-rng does. Paolo ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] [RFC] Hypervisor RNG and enumeration
On 29/10/14 13:45, Paolo Bonzini wrote: > > > 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(0x4F00) even if HYPERVISOR=0. What you > get back is undefined, but in all likelihood it won't be the > "CommonHVIntf" string. Microsoft already has a specification to obtain a random number via an ACPI device. The VM Generation ID. http://www.microsoft.com/en-us/download/details.aspx?id=30707 David ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] [RFC] Hypervisor RNG and enumeration
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(0x4F00) even if HYPERVISOR=0. What you get back is undefined, but in all likelihood it won't be the "CommonHVIntf" string. Paolo ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] [RFC] Hypervisor RNG and enumeration
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 4F00H, containing: > > * CPUID.4F00H.0H.EAX = max_commonhv_leaf > * CPUID.4F00H.0H.EBX = 0x6D6D6F43 > * CPUID.4F00H.0H.ECX = 0x56486E6F > * CPUID.4F00H.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 0x4F00 and 0x4FFF. 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 4F01H: hypervisor interface enumeration > -- > > If max_commonhv_leaf >= 0x4F01, 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.4F01H.i.EBX, CPUID.4F01H.i.ECX, and CPUID.4F01H.i.EDX > are the signature. > * CPUID.4F01H.i.EAX is the
