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

["H. Peter Anvin" <hpa@zytor.com>]

On 10/26/2012 08:42 AM, Anthony Liguori wrote:
>>
>> 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.
>

/dev/urandom is just plain *wrong*... it is feeding a PRNG into a PRNG 
which can best be described as "masturbation" and at worst as a 
"cryptographic usage violation."

/dev/hwrng is reasonable, in some ways; after all, the guest itself is 
expected to use rngd.  There are, however, at least two problems:

a) it means that the guest *has* to run rngd or a similar engine; if you 
have control over the guests it might be more efficient to run rngd in 
skip-test mode (I don't think that is currently implemented but it 
could/should be) and centralize all testing to the host.

A skip-test mode would also allow rngd to forward-feed shorter blocks 
than 2500 bytes.

b) if the host has no physical hwrng, /dev/hwrng will output nothing at 
all, which is worse than /dev/random in that situation.

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

We SHOULD NOT expose a PRNG here!  It is the same fail as using 
/dev/urandom (but worse)  The whole point is to inject actual entropy... 
a PRNG can (and typically will) just run in guest space.

>> 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)?

If you have rdrand you might just use it in the guest directly, unless 
you have a strong reason (migration?) not to do that.  Either way, for 
rdrand you need whitening similar to what rngd is doing (for *rdseed* 
you do not, but rdseed is not shipping yet.)

The startup issue is an interesting problem.  If you have full control 
over the guest it might be best to simply inject some entropy into the 
guest on startup via the initramfs or a disk image; that has its own 
awkwardness too, of course.  The one bit that could potentially be 
solved in Qemu would be an option to "don't start the guest until X 
bytes of entropy have been gathered."

Overall, I want to emphasize that we don't want to try solve generic 
problems in virtualization space... resource constraints on /dev/random 
is a generic host OS issue for example.

	-hpa

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