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