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

[Amit Shah <amit.shah@redhat.com>]

On (Mon) 28 May 2012 [09:33:57], Daniel P. Berrange wrote:
> On Sat, May 26, 2012 at 01:02:49AM +0530, 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
> 
> ACK to this ARGV design from a libvirt POV.
> 
> > 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}}
> 
> IIUC, there are three ways mgmt apps can use the RNG with the
> chardev
> 
>  - Wire it up to a source that just blindly provides all the
>    entropy QEMU desires (as you /dev/urandom example above)
> 
>  - Feed in a fixed amount of entropy every minute, regardless
>    of how much QEMU desires

This option currently won't do anything -- i.e. till the guest sends
across a buffer to be filled in, nothing will go to the guest, and the
data will just be buffered in the chardev layer till such a buffer
comes along.  It can be debatable on feeding entropy by pushing every
particular timeout, or just providing the freshest on-demand.
Advantage could be we have more random bits, disadvantage is this
could be throttled as the host went out of enough entropy.

>  - Feed in entropy on demand, in response to the ENTROPY_NEEDED
>    event notification (possibly throttling)
> 
> These options sounds like they should cover all reasonable needs,
> so gets my vote.

Great!

> Probably want to include the ENTROPY_NEEDED
> event in my patch which adds rate limiting to guest initiated
> events.

Yes, just depends in which order the patches go in.

Thanks,
		Amit