PRNGs don't "create entropy." Period. The guest will run its own PRNG.
Anthony Liguori <aligu...@us.ibm.com> wrote: >"H. Peter Anvin" <h...@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. -- Sent from my mobile phone. Please excuse brevity and lack of formatting.
