From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56062) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRm3o-0005No-J3 for qemu-devel@nongnu.org; Fri, 26 Oct 2012 11:43:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TRm3h-0008U3-TX for qemu-devel@nongnu.org; Fri, 26 Oct 2012 11:43:00 -0400 Received: from e28smtp01.in.ibm.com ([122.248.162.1]:60725) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRm3h-0008Sb-7t for qemu-devel@nongnu.org; Fri, 26 Oct 2012 11:42:53 -0400 Received: from /spool/local by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 26 Oct 2012 21:12:43 +0530 Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q9QFgaeN7077888 for ; Fri, 26 Oct 2012 21:12:36 +0530 Received: from d28av04.in.ibm.com (loopback [127.0.0.1]) by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q9QLCRX0019888 for ; Sat, 27 Oct 2012 08:12:27 +1100 From: Anthony Liguori In-Reply-To: <604401631.2277495.1351264128301.JavaMail.root@redhat.com> References: <604401631.2277495.1351264128301.JavaMail.root@redhat.com> Date: Fri, 26 Oct 2012 10:42:22 -0500 Message-ID: <871ugl44v5.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Amit Shah , qemu-devel@nongnu.org, Andreas Faerber , "H. Peter Anvin" Paolo Bonzini 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