From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45030) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDMec-0003wW-LF for qemu-devel@nongnu.org; Sun, 16 Sep 2012 17:45:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TDMeb-0008Qs-GO for qemu-devel@nongnu.org; Sun, 16 Sep 2012 17:45:26 -0400 Received: from terminus.zytor.com ([198.137.202.10]:58012) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDMea-0008B6-Hf for qemu-devel@nongnu.org; Sun, 16 Sep 2012 17:45:25 -0400 Message-ID: <505639C6.2050704@zytor.com> Date: Sun, 16 Sep 2012 13:42:46 -0700 From: "H. Peter Anvin" MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: Amit Shah Cc: qemu list , Anthony Liguori 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. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.