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

[Daniel P. Berrange]

On Tue, Jun 05, 2012 at 03:46:31PM +0530, Amit Shah wrote:
> On (Tue) 05 Jun 2012 [17:54:30], Anthony Liguori wrote:
> > 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.
> 
> In my view, qemu doesn't operate at a system-level where it can see
> how system entropy is being used.
> 
> libvirt does operate at that level.
> 
> For casual development, I don't want to have egd on my system to feed
> in entropy to the guest, and I don't need to know how to configure
> egd and then provide its output to qemu.
> 
> libvirt can do that for me.  But for development, I'd just want to be
> able to do something like
> 
> qemu -chardev socket,path=/tmp/foo,id=foo,server,nowait \
>      -device virtio-rng,chardev=foo
> 
> and then just feed in some data to /tmp/foo.

I tend to agree, while the EGD wire protocol may be useful if you
are wanting to connect QEMU to EGD, for apps that are just directly
mnanaging QEMU it imposes a unnecessary burden on apps, to learn
a new protocol in addition to their existing knowledge of QMP.

In addition, I don't think implementing the EGD protocol is mutually
exclusive with raw QEMU chardevs. eg enablement of an EGD protocol on
the chardev could reasonably be done as an optional feature ontop of
the raw chardev, in the same way that chardevs can be made to optionally
run the telnet line discipline.

I'd like to see us have the raw chardev impl + QMP event as a first
step, and then add EGD protocol on top of that (if desired) as a
second step.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|