[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 13:24:10 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

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

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.

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.

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.


Anthony Liguori


reply via email to

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