On Thu, Oct 30, 2014 at 5:21 AM, David Vrabel <david.vrabel@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
