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

[Amit Shah <amit.shah@redhat.com>]

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<amit.shah@redhat.com>
> >>
> >>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.

In the meantime, I'll add a rate-limiting option to the device, it
does seem like a good idea to implement nevertheless.

		Amit