From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40755) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUitV-00031P-Ho for qemu-devel@nongnu.org; Wed, 16 May 2012 14:24:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SUitT-0005wO-CK for qemu-devel@nongnu.org; Wed, 16 May 2012 14:24:17 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:46083) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUitT-0005vd-5e for qemu-devel@nongnu.org; Wed, 16 May 2012 14:24:15 -0400 Received: by pbbro12 with SMTP id ro12so1856483pbb.4 for ; Wed, 16 May 2012 11:24:13 -0700 (PDT) Message-ID: <4FB3F0CA.8020505@codemonkey.ws> Date: Wed, 16 May 2012 13:24:10 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4FB3AA86.3080507@codemonkey.ws> <20120516134534.GK22979@redhat.com> <20120516172624.GB16342@amit.redhat.com> In-Reply-To: <20120516172624.GB16342@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/16/2012 12:26 PM, Amit Shah wrote: > On (Wed) 16 May 2012 [14:45:34], Daniel P. Berrange wrote: >> On Wed, May 16, 2012 at 08:24:22AM -0500, 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. >> >> Ultimately I think you need to have a push mechanism, where an external >> process feeds entropy to QEMU, rather than a pull mechanism where QEMU >> grabs entropy itself. > > Yes, that's the goal. > > That was my first instinct as well. However, we already have guests > which have the current virtio-rng driver that works only in pull > mode. Also, Linux's hw-rng interface doesn't have a pull mechanism at > all -- it asks the h/w for more entropy when the OS is low on it. > >> I tend to think that virtio-rng should have a chardev backend associated >> with it. The driver should just read from this chardev to get its entropy. > > I even started with this approach. Adapting the chardev layer to > actually read from a source of data, only when needed (for the > pull-based mechanism) quickly turned ugly. > > When we do get a push-based mechanism working, we'll then also have to > think of buffering the data from the daemon somewhere. It's not going > to be ideal. push == pull with flow control. There's no need to implement a different guest interface. > >> Either libvirtd, or better yet a separate virt-entropyd daemonm would >> connect to each guest& feed the entropy into each guest according to >> some desired metrics. > > I'd prefer a separate daemon. There already is egd, which we can use. > However, there are restrictions with certification (as always). > Adding new daemons to the mix increases complexity and the time it > takes for certification, so doing it in libvirt may end up to be the > preferred approach. I don't think time to certify is a reasonable technical consideration. Regards, Anthony Liguori > > Amit