From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49415) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRoa5-0001RZ-H3 for qemu-devel@nongnu.org; Fri, 26 Oct 2012 14:24:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TRoa3-0006KV-Uu for qemu-devel@nongnu.org; Fri, 26 Oct 2012 14:24:29 -0400 Received: from e28smtp06.in.ibm.com ([122.248.162.6]:58315) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRoa3-0006Ia-8g for qemu-devel@nongnu.org; Fri, 26 Oct 2012 14:24:27 -0400 Received: from /spool/local by e28smtp06.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 26 Oct 2012 23:54:23 +0530 Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66]) by d28relay04.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q9QIOIix62652496 for ; Fri, 26 Oct 2012 23:54:19 +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 q9QNs9iV020200 for ; Sat, 27 Oct 2012 10:54:09 +1100 From: Anthony Liguori In-Reply-To: <508AB5C0.2000304@zytor.com> References: <604401631.2277495.1351264128301.JavaMail.root@redhat.com> <871ugl44v5.fsf@codemonkey.ws> <508AB5C0.2000304@zytor.com> Date: Fri, 26 Oct 2012 13:24:06 -0500 Message-ID: <87r4ol2it5.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: "H. Peter Anvin" Cc: Ted Ts'o , Dustin Kirkland , qemu-devel@nongnu.org, George Wilson , Amit Shah , Paolo Bonzini , Kent Yoder , Andreas Faerber "H. Peter Anvin" 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.