Paolo Bonzini <pbonz...@redhat.com> writes: >> This series implements the backend and frontend infrastructure for >> virtio-rng. >> This is similar to previous series sent out by both Amit and myself >> although it has been trimmed down considerably. >> >> In terms of backends, a file and EGD backend are supported. The file >> defaults >> to /dev/random based on the feedback from Peter. It's still possible >> to support /dev/urandom though as an entropy source by overriding the file >> name. >> >> I think this series is ready to merge. > > 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. It's just a matter of what the default is and I feel comfortable that if someone can provide a *concrete* demonstration of what the best default is, we can change it later on. > At this point, /dev/hwrng (or rdrand) seems just as good as > /dev/random as a source for virtio-rng (and even better, it is not > starved as easily). I've been told that hwrng sources need to be passed through a whitening function in order to be suitable for PRNG generators. Since we expose a /dev/hwrng in the guest, perhaps this doesn't matter... > I think RngBackend is over-engineered. What other backends do you plan > on adding? 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. > 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)? I don't like overloading chardev to representate any !block device backend which is what I fear we're doing here. EGD is more than just a dumb pipe of data too. It's got a way to query available entropy. I have a strong suspicion that over time, we'll add methods to virtio-rng to query available entropy. That would mean adding a backend specific ioctl to the chardev layer which is pretty ugly. The overhead of creating a separate backend to begin with is extremely small. We're talking about dozens of lines of code. So I don't see what the problem is. Regards, Anthony Liguori > > Paolo