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.