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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
