[Top][All Lists]

[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

From: H. Peter Anvin
Subject: Re: [Qemu-devel] [PATCH v3 0/1] virtio-rng: hardware random number generator
Date: Sun, 16 Sep 2012 13:42:46 -0700
User-agent: 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.

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.


H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]