From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60331) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWZOk-0005Bk-IT for qemu-devel@nongnu.org; Mon, 21 May 2012 16:40:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWZOi-0001Ay-MK for qemu-devel@nongnu.org; Mon, 21 May 2012 16:40:10 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:53274) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWZOi-0001AK-Ca for qemu-devel@nongnu.org; Mon, 21 May 2012 16:40:08 -0400 Received: by obbwd20 with SMTP id wd20so10774254obb.4 for ; Mon, 21 May 2012 13:40:06 -0700 (PDT) Message-ID: <4FBAA6F3.3010007@codemonkey.ws> Date: Mon, 21 May 2012 15:34:59 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4FB3AA86.3080507@codemonkey.ws> <20120516172143.GA16342@amit.redhat.com> <4FB3F08F.2070303@codemonkey.ws> <20120521193926.GD14541@amit.redhat.com> In-Reply-To: <20120521193926.GD14541@amit.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/1] virtio-rng: device to send host entropy to guest List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Amit Shah Cc: qemu list On 05/21/2012 02:39 PM, Amit Shah wrote: > On (Wed) 16 May 2012 [13:23:11], Anthony Liguori wrote: >> On 05/16/2012 12:21 PM, Amit Shah wrote: >>> On (Wed) 16 May 2012 [08:24:22], Anthony Liguori wrote: >>>> On 05/16/2012 06:30 AM, Amit Shah wrote: >>>>> The Linux kernel already has a virtio-rng driver, this is the device >>>>> implementation. >>>>> >>>>> When Linux needs more entropy, it puts a buffer in the vq. We then put >>>>> entropy into that buffer, and push it back to the guest. >>>>> >>>>> Feeding randomness from host's /dev/urandom into the guest is >>>>> sufficient, so this is a simple implementation that opens /dev/urandom >>>>> and reads from it whenever required. >>>>> >>>>> Invocation is simple: >>>>> >>>>> qemu ... -device virtio-rng-pci >>>>> >>>>> In the guest, we see >>>>> >>>>> $ cat /sys/devices/virtual/misc/hw_random/rng_available >>>>> virtio >>>>> >>>>> $ cat /sys/devices/virtual/misc/hw_random/rng_current >>>>> virtio >>>>> >>>>> There are ways to extend the device to be more generic and collect >>>>> entropy from other sources, but this is simple enough and works for now. >>>>> >>>>> Signed-off-by: Amit Shah >>>> >>>> It's not this simple unfortunately. >>>> >>>> If you did this with libvirt, one guest could exhaust the available >>>> entropy for the remaining guests. This could be used as a mechanism >>>> for one guest to attack another (reducing the available entropy for >>>> key generation). >>>> >>>> You need to rate limit the amount of entropy that a guest can obtain >>>> to allow management tools to mitigate this attack. >>> >>> Hm, rate-limiting is a good point. However, we're using /dev/urandom >>> here, which is nonblocking, and will keep on providing data as long as >>> we keep reading. >> >> But you're still exhausting the entropy pool (which is a global >> resource). That's the problem. > > I understand. It's been shown, however, that /dev/urandom isn't > easily exhausted, and can be used as a reliable random source for > quite a few years without new seeding. And even if a guest (or more) > is malicious, the guest doing such activities would itself continue to > generate some seed for the host's pool, strengthening /dev/urandom. > > I don't know where to cite the data from, but I'll pass on that info > when I have a reference. Okay, I need to some type of reference here. Not implementing virtio-rng for all of these years wasn't a simple oversight. It was specifically out of fear of exhausting the entropy pool. I'm pretty opposed to merging this without addressing entropy exhaustion because it's a subtle enough issue that I don't think most users would be capable of understanding the ramifications. Regards, Anthony Liguori > > In the meantime, I'll add a rate-limiting option to the device, it > does seem like a good idea to implement nevertheless. > > Amit