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

[H. Peter Anvin]

PRNGs don't "create entropy."  Period.

The guest will run its own PRNG.

Anthony Liguori <address@hidden> wrote:

>"H. Peter Anvin" <address@hidden> 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.

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.