From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51864) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDRu0-0006P1-O1 for qemu-devel@nongnu.org; Sun, 16 Sep 2012 23:21:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TDRty-0007Ra-Uh for qemu-devel@nongnu.org; Sun, 16 Sep 2012 23:21:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24144) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDRty-0007RM-MS for qemu-devel@nongnu.org; Sun, 16 Sep 2012 23:21:38 -0400 Date: Mon, 17 Sep 2012 08:51:31 +0530 From: Amit Shah Message-ID: <20120917032131.GB22729@amit.redhat.com> References: <505639C6.2050704@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <505639C6.2050704@zytor.com> Subject: Re: [Qemu-devel] [PATCH v3 0/1] virtio-rng: hardware random number generator List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "H. Peter Anvin" Cc: qemu list , Anthony Liguori On (Sun) 16 Sep 2012 [13:42:46], H. Peter Anvin wrote: > On 06/19/2012 11:59 PM, Amit Shah wrote: > >Hello, > > > >Here's the 3rd iteration of the virtio-rng device. This update just > >rebases the patch on top of current master. > > > >Details on the patch in the commit message. > > > > Hi everyone... > > I just stumbled on this patchset after realizing that the virtio-rng > support still is not even in the Qemu git tree even though the > kernel side has been there for four years(!) > > It seems this support has been stuck in "overengineering hell" for > years. I have to admit to having a bit of a confusion about what is > so hard about reading from a file descriptor, which may return > partial reads. I understand the fairness argument, but I would > argue that if it is an actual problem should be solved in the kernel > and therefore benefit all types of applications rather than at the > application level (which Qemu, effectively, is.) > > However, one key error I spotted was using /dev/urandom. Using > /dev/urandom is a very serious cryptographic error, as well as > completely pointless. > > The whole point of this is to provided distilled entropy to the > guest, so that it can seed true entropy into *its* entropy pool. As > such, using /dev/urandom is: > > a) needlessly slow. It will churn the host kernel PRNG needlessly, > and not provide any backpressure when the host pool is already > drained. Using /dev/random instead will indicate that the host > pool is drained, and not pass a bunch of PRNG noise across an > expensive channel when the PRNG in the *guest* could do the PRNG > expansion just as well. > > b) cryptographically incorrect. This will tell the guest that it > is being provided with entropy that it doesn't actually have, which > will mean the guest severely overestimates the entropy that it has > available to it. To put it differently: /dev/random in the guest > will behave like (a very expensive version of) /dev/urandom from > a cryptographic point of view. > > The right interface to the host kernel, therefore, is /dev/random. Agreed with your points -- /dev/random on the host itself could be fed in via a real hwrng. Also, for the fairness arguments, several guests doing IO also contribute to the random pool. The ideal interface, though, in qemu should be sourcing entropy from a file descriptor, and the admin chooses what he wants to source entropy from - /dev/random, /dev/urandom, or even /dev/hwrng. Amit