Re: [Qemu-devel] [PATCH 2/4] virtio-rng-pci: create a default backend if none exists

[Paolo Bonzini]

Il 26/10/2012 21:51, Anthony Liguori ha scritto:
>> > If you make the default /dev/hwrng, however, that would be ok.
> /dev/hwrng may be (and stay) empty which seems unfortunate.

Unfortunate, but at least not wrong.

> I was thinking /dev/urandom would be a good pragmatic choice though.

No.

/dev/urandom is actively wrong because it provides the guest with the
illusion of an infinite source of entropy, while the guest is really
being fed with an infinite source of pseudo-random numbers.

/dev/random as a default is bad because on hosts without neither hwrng
nor rdrand it completely depletes the host's entropy pool.  Thus it
denies access to entropy to other programs running in the host.

I thought /dev/random with some throttling would be good, especially if
somehow the guest can be told to run rngd in skip-test mode, e.g. via a
virtio-rng feature bit.  Peter's last messages make me wonder if this is
correct.  If it is, the throttling can be implemented either in QEMU or
outside it (via a daemon that speaks the same protocol as egd).

/dev/random might be good in the special case where rngd is being run in
the host, and there is an hwrng or rdrand to feed rngd.  In this case
the guest can also be run in skip-test mode.  However, I don't have a
machine at hand (it's Friday evening here) to test whether rngd could
keep up, or a malicious guest would instead also deplete the host's
entropy tool too badly.

/dev/null makes the guest behave exactly as if no virtio-rng-pci is
present, so it is at least not wrong.

rdrand and /dev/hwrng seem to be the best choice at least to me.  Peter
seemed to agree initially, then said "This is surreal.  Output from
/dev/hwrng turns into output for /dev/random... it us guaranteed worse;
period, end of story".  I'm confused.

I hope the above is not too inaccurate and at least a decent way to
reset the discussion.

Paolo