[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 1/1] virtio-rng: device to send host entropy to guest
Date: Wed, 16 May 2012 09:02:03 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 05/16/2012 08:53 AM, Daniel P. Berrange wrote:
On Wed, May 16, 2012 at 08:48:20AM -0500, Anthony Liguori wrote:
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

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

   $ cat /sys/devices/virtual/misc/hw_random/rng_current

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.

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.

The nice thing about just using a plain chardev backend for virtiorng
is that it would let you have the flexibility to integrate with any kind
of entropy daemon, or even just run without a daemon&  rely on some other
process to periodically open the chardev&  feed in data.


But there is an entropy daemon that does use a protocol. The protocol may be "just read raw random data" but we should at least check to make sure that is the protocol.


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]