[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 21:27:22 -0700 |
User-agent: |
K-9 Mail for Android |
Right, obviously. However, under no circumstances should /dev/urandom be used!
Amit Shah <address@hidden> 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.