Re: [Qemu-devel] [PATCH v2 1/1] virtio-rng: hardware random number generator device

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/05/2012 05:41 PM, Amit Shah wrote:
> On (Mon) 04 Jun 2012 [19:04:41], Anthony Liguori wrote:
>> On 05/26/2012 04:20 AM, Amit Shah wrote:
>>> On (Fri) 25 May 2012 [15:00:53], Anthony Liguori wrote:
>>>> On 05/25/2012 02:32 PM, Amit Shah wrote:
>>>>> The Linux kernel already has a virtio-rng driver, this is the device
>>>>> implementation.
>>>>>
>>>>> When the guest asks for entropy from the virtio hwrng, it puts a buffer
>>>>> in the vq.  We then put entropy into that buffer, and push it back to
>>>>> the guest.
>>>>>
>>>>> The chardev connected to this device is fed the data to be sent to the
>>>>> guest.
>>>>>
>>>>> Invocation is simple:
>>>>>
>>>>>    $ qemu ... -device virtio-rng-pci,chardev=foo
>>>>>
>>>>> 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
>>>>>
>>>>>    # cat /dev/hwrng
>>>>>
>>>>> Simply feeding /dev/urandom from the host to the chardev is sufficient:
>>>>>
>>>>>    $ qemu ... -chardev socket,path=/tmp/foo,server,nowait,id=foo \
>>>>>               -device virtio-rng,chardev=foo
>>>>>
>>>>>    $ nc -U /tmp/foo<    /dev/urandom
>>>>>
>>>>> A QMP event is sent for interested apps to monitor activity and send the
>>>>> appropriate number of bytes that get asked by the guest:
>>>>>
>>>>>    {"timestamp": {"seconds": 1337966878, "microseconds": 517009}, \
>>>>>     "event": "ENTROPY_NEEDED", "data": {"bytes": 64}}
>>>>
>>>> I don't understand the point of this event.  Can't a management app
>>>> just create a socket and then it can see all the requests the guest
>>>> makes?
>>>
>>> How?  With the chardev, it can only keep feeding data, and that data
>>> will be consumed when chr_can_read() returns>   0.  And even then the
>>> mgmt app has no idea how much data was asked for, and how much was
>>> consumed.
>>
>> Okay, then the right approach is to use a message protocol where
>> QEMU asks for a certain amount of data and then the daemon sends it
>> back.
>
> Why is a message protocol necessary?  And a daemon isn't necessary,
> too.
>
>> I think this is pretty much why the egd protocol exists, no?  Why
>> not just implement egd protocol support?
>
> Perhaps I'm not getting what you're saying.
>
> What we have here, via the event, is to tell the mgmt app that the
> guest has need for entropy.

*out-of-band*

Why not just make that all in-band?

I understand you're trying to accomodate a use-case of feeding /dev/random to 
QEMU.  I don't think this is a necessary use-case though because I don't think 
it's correct.  You need to use an entropy daemon of some sort to make sure 
entropy is being distributed in a fair fashion.

> The guest also tells us exactly how many
> bytes it needs.  We're just passing on that info to the mgmt app, if
> it needs it.
>
> In any case, any data pushed down the chardev will be consumed by the
> device, and sent to the guest when the guest puts a buf in the vq.
>
>> Once we introduce a protocol of any form (even raw), we have to
>> support it forever so let's not do it carelessly.
>
> There's no need for a protocol at all here.

The event *is* a protocol.  That's the point.

Here's what you're making a management app do:

1) Open a socket
2) Feed socket fd to QEMU
3) Listen for event on QMP for entropy request
4) Read entropy based on (3) from /dev/random
5) Send entropy to socket to QEMU

This is pretty silly when you can just do:

1) Open a socket
2) Listen for entropy request
3) Read entry based on (2) from /dev/random
4) Respond to (2) with (3)

And there's already a tool and protocol for exactly the above--egd.

There's simply no good reason to involve QMP here.

Regards,

Anthony Liguori

   Can you skim through the
> code and point out where you think we're disagreeing?
>
> 		Amit