Proposed F19 Feature: Virtio RNG

[Matthew Garrett]

On Fri, Feb 01, 2013 at 04:39:17PM -0500, Bill Nottingham wrote:

> What exactly feeds /dev/random in the guest in the cases where this doesn't
> exist, and how do we cope with this obviously making /dev/random exhaustion
> in the host much more likely? (Other than assume that a HW RNG is in the
> host.)

At the moment the guest gets its entropy in the same way that bare metal 
would - various interrupts are picked up and fed into the entropy pool. 
The problem there is that (a) there's typically far fewer of these 
events on a guest, and (b) how much do you really trust those timings to 
be random when you're at the whims of an external process scheduler. So, 
right now, you have very little entropy in the guest and what entropy 
you do have may not be worth a great deal. In a lot of cases, 
/dev/urandom is probably running off the original seed value that 
happened to be sitting in your image file. The same one that's probably 
running in a bunch of other guests.

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.

> 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.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org