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

[Anthony Liguori <aliguori@us.ibm.com>]

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

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

I don't understand your logic here.

>From the discussions I've had, the quality of the randomness from a
*well seeded* PRNG ought to be good enough to act as an entropy source
within the guest.

What qualifies as well seeded is a bit difficult to pin down with more
specificity than "kilobytes of data".

I stayed away from /dev/urandom primarily because it's impossible to
determine if it's well seeded or not making urandom dangerous to use.

But using a PRNG makes sense to me when dealing with multiple guests.
If you have a finite source of entropy in the host, using a PRNG to
create unique entropy for each guest is certainly better than
duplicating entropy.

Adding Ted T'so and a few others to CC in hopes that they can chime in
here too.

FWIW, none of this should affect this series being merged as it can use
a variety of different inputs.  But I would like to have a strong
recommendation for what people should use (and make that default) so I'd
really like to get a clear answer here.

Regards,

Anthony Liguori

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