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

[Andy Lutomirski <luto@xxxxxxxxxxxxxx>]

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

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