On (Wed) 16 May 2012 [13:24:10], Anthony Liguori wrote:
> On 05/16/2012 12:26 PM, Amit Shah wrote:
> >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<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.
> >>
> >>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.
>
> push == pull with flow control. There's no need to implement a
> different guest interface.
Though, the current implementation can be easily extended -- if we do
go without a chardev for v1 for virtio-rng, with qemu directly opening
urandom and feeding entropy, libvirt just has to add a
'virtio-rng-pci' device. When the ',chardev' property becomes
available, it can connect the chardev to itself or a daemon and start
feeding data.
> >>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.
>
> I don't think time to certify is a reasonable technical consideration.
Absolutely -- but if it's as easy to implement it in libvirt vs
another standalone program, the libvirt approach should be preferred
considering the above.
Amit
