Re: [Qemu-devel] [PATCH 1/1] virtio-rng: device to send host entropy to guest

[Amit Shah]

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<address@hidden>
> > 
> > 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.

> 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.

                Amit