On 05/16/2012 08:45 AM, 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.
A previous patch didn't open urandom directly but instead talked to an entropy
daemon. This approach would allow libvirt to hand out entropy as it saw fit
without requiring a new driver.
Regards,
Anthony Liguori
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.
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.
Regards,
Daniel