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