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

[Anthony Liguori <anthony@codemonkey.ws>]

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.shah@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.

>
>> 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.

Regards,

Anthony Liguori

>
> 		Amit