Right, obviously. However, under no circumstances should /dev/urandom be used!
Amit Shah <amit.s...@redhat.com> wrote: >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 -- Sent from my mobile phone. Please excuse brevity and lack of formatting.
