From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53568) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUenz-0001Wj-M6 for qemu-devel@nongnu.org; Wed, 16 May 2012 10:02:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SUenp-0003DU-6X for qemu-devel@nongnu.org; Wed, 16 May 2012 10:02:19 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:44669) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUenp-0003D8-07 for qemu-devel@nongnu.org; Wed, 16 May 2012 10:02:09 -0400 Received: by dadv2 with SMTP id v2so1338241dad.4 for ; Wed, 16 May 2012 07:02:07 -0700 (PDT) Message-ID: <4FB3B35B.5090604@codemonkey.ws> Date: Wed, 16 May 2012 09:02:03 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4FB3AA86.3080507@codemonkey.ws> <20120516134534.GK22979@redhat.com> <4FB3B024.8020600@codemonkey.ws> <20120516135328.GL22979@redhat.com> In-Reply-To: <20120516135328.GL22979@redhat.com> Content-Type: text/plain; charset=UTF-8; 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: "Daniel P. Berrange" Cc: Amit Shah , qemu list On 05/16/2012 08:53 AM, Daniel P. Berrange wrote: > On Wed, May 16, 2012 at 08:48:20AM -0500, Anthony Liguori wrote: >> On 05/16/2012 08:45 AM, 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. >> >> A previous patch didn't open urandom directly but instead talked to >> an entropy daemon. This approach would allow libvirt to hand out >> entropy as it saw fit without requiring a new driver. > > The nice thing about just using a plain chardev backend for virtiorng > is that it would let you have the flexibility to integrate with any kind > of entropy daemon, or even just run without a daemon& rely on some other > process to periodically open the chardev& feed in data. Ack. But there is an entropy daemon that does use a protocol. The protocol may be "just read raw random data" but we should at least check to make sure that is the protocol. Regards, Anthony Liguori > >>> 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. >>> 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. > > Regards, > Daniel