[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH v2 1/1] virtio-rng: hardware random number generator device
Date: Tue, 05 Jun 2012 17:54:30 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

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

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

Invocation is simple:

   $ qemu ... -device virtio-rng-pci,chardev=foo

In the guest, we see

   $ cat /sys/devices/virtual/misc/hw_random/rng_available

   $ cat /sys/devices/virtual/misc/hw_random/rng_current

   # 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

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

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

Why is a message protocol necessary?  And a daemon isn't necessary,

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.


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.


Anthony Liguori

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]