Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support

[Amit Shah <amit.shah@redhat.com>]

On (Fri) 26 Oct 2012 [13:24:06], Anthony Liguori wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
> 
> > On 10/26/2012 08:42 AM, Anthony Liguori wrote:
> >>>
> >>> Is /dev/random even appropriate to feed rngd?
> >>>
> >>> rngd needs _a lot_ of entropy to even start working.  Its randomness
> >>> test works in groups of 20000 bits. On a system without an hardware
> >>> RNG, /dev/random can hardly produce 4000 bits/minute.  This means a
> >>> guest will not get any entropy boost for 5 minutes after it's started,
> >>> even if we allow it to exhaust the parent's entropy.
> >>
> >> I don't know, but rng-random is a non-blocking backend so it can handle
> >> /dev/random, /dev/urandom, or /dev/hwrng.
> >>
> >
> > /dev/urandom is just plain *wrong*... it is feeding a PRNG into a PRNG 
> > which can best be described as "masturbation" and at worst as a 
> > "cryptographic usage violation."
> 
> I don't understand your logic here.
> 
> From the discussions I've had, the quality of the randomness from a
> *well seeded* PRNG ought to be good enough to act as an entropy source
> within the guest.
> 
> What qualifies as well seeded is a bit difficult to pin down with more
> specificity than "kilobytes of data".
> 
> I stayed away from /dev/urandom primarily because it's impossible to
> determine if it's well seeded or not making urandom dangerous to use.
> 
> But using a PRNG makes sense to me when dealing with multiple guests.
> If you have a finite source of entropy in the host, using a PRNG to
> create unique entropy for each guest is certainly better than
> duplicating entropy.

One solution could be to feed host's /dev/urandom to readers of
guests' /dev/urandom.  We could then pass the rare true entropy bits
from host's /dev/hwrng or /dev/random to the guest via
virtio-rng-pci's /dev/hwrng interface in the guest.

If this is a valid idea (host /dev/urandom goes directly to guest's
/dev/urandom), we would need some guest-side surgery, but it shouldn't
be huge work, and would remove several bottlenecks.

Is this a very crazy idea?


		Amit