Re: [Qemu-devel] [PATCH v3 0/1] virtio-rng: hardware random number generator

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

On (Sun) 16 Sep 2012 [13:42:46], H. Peter Anvin wrote:
> On 06/19/2012 11:59 PM, Amit Shah wrote:
> >Hello,
> >
> >Here's the 3rd iteration of the virtio-rng device.  This update just
> >rebases the patch on top of current master.
> >
> >Details on the patch in the commit message.
> >
> 
> Hi everyone...
> 
> I just stumbled on this patchset after realizing that the virtio-rng
> support still is not even in the Qemu git tree even though the
> kernel side has been there for four years(!)
> 
> It seems this support has been stuck in "overengineering hell" for
> years.  I have to admit to having a bit of a confusion about what is
> so hard about reading from a file descriptor, which may return
> partial reads.  I understand the fairness argument, but I would
> argue that if it is an actual problem should be solved in the kernel
> and therefore benefit all types of applications rather than at the
> application level (which Qemu, effectively, is.)
> 
> However, one key error I spotted was using /dev/urandom.  Using
> /dev/urandom is a very serious cryptographic error, as well as
> completely pointless.
> 
> The whole point of this is to provided distilled entropy to the
> guest, so that it can seed true entropy into *its* entropy pool.  As
> such, using /dev/urandom is:
> 
> a) needlessly slow.  It will churn the host kernel PRNG needlessly,
>    and not provide any backpressure when the host pool is already
>    drained.  Using /dev/random instead will indicate that the host
>    pool is drained, and not pass a bunch of PRNG noise across an
>    expensive channel when the PRNG in the *guest* could do the PRNG
>    expansion just as well.
> 
> b) cryptographically incorrect.  This will tell the guest that it
>    is being provided with entropy that it doesn't actually have, which
>    will mean the guest severely overestimates the entropy that it has
>    available to it.  To put it differently: /dev/random in the guest
>    will behave like (a very expensive version of) /dev/urandom from
>    a cryptographic point of view.
> 
> The right interface to the host kernel, therefore, is /dev/random.

Agreed with your points -- /dev/random on the host itself could be fed
in via a real hwrng.  Also, for the fairness arguments, several guests
doing IO also contribute to the random pool.

The ideal interface, though, in qemu should be sourcing entropy from
a file descriptor, and the admin chooses what he wants to source
entropy from - /dev/random, /dev/urandom, or even /dev/hwrng.

		Amit