Proposed F19 Feature: Virtio RNG

[Paolo Bonzini]

Il 02/02/2013 00:40, Matthew Garrett ha scritto:
> This patchset means that there's a /dev/hwrng available in the guest, so 
> you still need to run something like rngd to mix that into the kernel's 
> entropy pool. You're right that the total amount of entropy is still 
> limited to that available on the host, and it does make host-side 
> exhaustion more likely. There's not a lot that can be done about that 
> other than providing other sources of entropy, and long-term this is 
> going to be fixed once everyone's moved to Ivy Bridge and has an 
> unprivileged instruction to hand out entropy.

If you're talking about RDRAND, it doesn't hand out entropy.  That's
RDSEED, which will only come with Haswell.

RDRAND only hands out random numbers.  We plan to add QEMU support for
using RDRAND directly (with whitening, similar to rngd), but it is not
in yet.  Right now what you do is use rngd in the host to feed
/dev/random with random numbers from RDRAND, connect /dev/random to
virtio-rng.

In either case, in the end the guest will have to run rngd to feed the
entropy into virtio-rng.

BTW, virtio-rng really only works well if you have a hardware RNG in the
host.  Otherwise, the host kernel will take too much time (a few
minutes) before producing enough entropy to feed the FIPS tests in the
guest, and during this time the host will be entropy-starved.

Paolo

>> Given FIPS paranoia about RNG sources, does this have knock-on effects in
>> the FIPS compliance of guests depending on how it's fed in the host?
> 
> I'm not convinced that you could currently claim with a straight face 
> that guests meet any sort of FIPS standard for random numbers.
>