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(a)srcf.ucam.org