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

[Anthony Liguori <anthony@codemonkey.ws>]

On 05/21/2012 02:39 PM, Amit Shah wrote:
> On (Wed) 16 May 2012 [13:23:11], Anthony Liguori wrote:
>> On 05/16/2012 12:21 PM, Amit Shah wrote:
>>> On (Wed) 16 May 2012 [08:24:22], 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.
>>>
>>> Hm, rate-limiting is a good point.  However, we're using /dev/urandom
>>> here, which is nonblocking, and will keep on providing data as long as
>>> we keep reading.
>>
>> But you're still exhausting the entropy pool (which is a global
>> resource). That's the problem.
>
> I understand.  It's been shown, however, that /dev/urandom isn't
> easily exhausted, and can be used as a reliable random source for
> quite a few years without new seeding.  And even if a guest (or more)
> is malicious, the guest doing such activities would itself continue to
> generate some seed for the host's pool, strengthening /dev/urandom.
>
> I don't know where to cite the data from, but I'll pass on that info
> when I have a reference.

Okay, I need to some type of reference here.

Not implementing virtio-rng for all of these years wasn't a simple oversight. 
It was specifically out of fear of exhausting the entropy pool.

I'm pretty opposed to merging this without addressing entropy exhaustion because 
it's a subtle enough issue that I don't think most users would be capable of 
understanding the ramifications.

Regards,

Anthony Liguori

>
> In the meantime, I'll add a rate-limiting option to the device, it
> does seem like a good idea to implement nevertheless.
>
> 		Amit