Re: [Qemu-devel] [PATCH v3 0/1] virtio-rng: hardware random number generator

[Anthony Liguori <anthony@codemonkey.ws>]

"H. Peter Anvin" <hpa@zytor.com> writes:

> 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(!)

The kernel implementation was done for lguest.  No implementation was
done for QEMU.

A couple have been attempted since then.  This most recent one will go
in.  However...

> 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.

This is *exactly* what the problem is.

If using /dev/urandom is pointless--and so far, many people have made
compelling arguments that it is--then using /dev/random is seemingly
impossible to do fairly.

The virtio-rng interface doesn't have any notion of guarantee of entropy
availability.  The guest just keeps requesting entropy with no
indication to the hypervisor of what it should and shouldn't give.

Since /dev/random is a finite pool, it's quite possible that one guest
could quickly exhaust /dev/random for all other guests.  How is this not
a clear denial of service?

This is why supporting EGD is so important IMHO.  Something else needs
to deal with handing out entropy in a responsible way.

Anyway, this is on my list for 1.3.  The series just needs some light
dusting before resubmission.

Regards,

Anthony Liguori

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