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

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

On (Mon) 21 May 2012 [15:34:59], Anthony Liguori wrote:
> 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<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.
> 
> 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.

Yes, I understand.  We just have to wait for the references.

There is /proc/sys/kernel/random/entropy_avail and qemu can be
configured to never let that number go below a certain watermark.
However, libvirt is in a better position to understand how the system
works, and how much demand for entropy comes from multiple guests.

Having thought more about it, qemu can't really make the call
rate-limiting.

So I think we should leave this to libvirt: qemu can emit an event,
like ENTROPY_NEEDED along with the number of bytes that got requested
by the guest.  libvirt can then fill in the bytes via a chardev.  If
libvirt wants to rate-limit this particular guest, it can just not
provide any data (for a certain amount of time).

This also then doesn't depend on the chardev flow control work to land
before this gets implemented.

Also, the patch carried in this thread can be enabled for developer
debugging (i.e. -device virtio-rng-pci w/o any chardev).

Does this sound OK?

		Amit