Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support

[Anthony Liguori]

Paolo Bonzini <address@hidden> writes:

>> This series implements the backend and frontend infrastructure for 
>> virtio-rng.
>> This is similar to previous series sent out by both Amit and myself
>> although it has been trimmed down considerably.
>> 
>> In terms of backends, a file and EGD backend are supported.  The file 
>> defaults
>> to /dev/random based on the feedback from Peter.  It's still possible
>> to support /dev/urandom though as an entropy source by overriding the file 
>> name.
>> 
>> I think this series is ready to merge.
>
> Is /dev/random even appropriate to feed rngd?
>
> rngd needs _a lot_ of entropy to even start working.  Its randomness
> test works in groups of 20000 bits. On a system without an hardware
> RNG, /dev/random can hardly produce 4000 bits/minute.  This means a
> guest will not get any entropy boost for 5 minutes after it's started,
> even if we allow it to exhaust the parent's entropy.

I don't know, but rng-random is a non-blocking backend so it can handle
/dev/random, /dev/urandom, or /dev/hwrng.

It's just a matter of what the default is and I feel comfortable that if
someone can provide a *concrete* demonstration of what the best default
is, we can change it later on.

> At this point, /dev/hwrng (or rdrand) seems just as good as
> /dev/random as a source for virtio-rng (and even better, it is not
> starved as easily).

I've been told that hwrng sources need to be passed through a whitening
function in order to be suitable for PRNG generators.  Since we expose a
/dev/hwrng in the guest, perhaps this doesn't matter...

> I think RngBackend is over-engineered. What other backends do you plan
> on adding?

Stefan Berger suggested a backend that uses a PRNG in FreeBL.  That's
probably the best default since it punts to a userspace library to deal
with ensuring there's adequate whitening/entropy to start with.

> Maybe rdrand, but that's just a chardev---so why isn't this enough:
>
>   -chardev file,source=on,path=/dev/hwrng,id=chr0  -device 
> virtio-rng-pci,file=chr0
>   -chardev rdrand,id=chr0                          -device 
> virtio-rng-pci,file=chr0
>   -chardev socket,host=localhost,port=1024,id=chr0 -device 
> virtio-rng-pci,rng=chr0,egd=on
>
> (which I suggested in my reply to Amit)?

I don't like overloading chardev to representate any !block device
backend which is what I fear we're doing here.

EGD is more than just a dumb pipe of data too.  It's got a way to query
available entropy.  I have a strong suspicion that over time, we'll add
methods to virtio-rng to query available entropy.  That would mean
adding a backend specific ioctl to the chardev layer which is pretty
ugly.

The overhead of creating a separate backend to begin with is extremely
small.  We're talking about dozens of lines of code.  So I don't see
what the problem is.

Regards,

Anthony Liguori

>
> Paolo