[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3 0/1] virtio-rng: hardware random number gener
H. Peter Anvin
Re: [Qemu-devel] [PATCH v3 0/1] virtio-rng: hardware random number generator
Sun, 16 Sep 2012 13:42:46 -0700
Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0
On 06/19/2012 11:59 PM, Amit Shah wrote:
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.
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
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.
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
- Re: [Qemu-devel] [PATCH v3 0/1] virtio-rng: hardware random number generator,
H. Peter Anvin <=