Features/VirtIORNG: Difference between revisions

From QEMU
m (Add (empty) section on egd)
(→‎Status: grammar corrections)
Line 5: Line 5:
== Status ==
== Status ==


Support for the VirtIO RNG device has been added to the QEMU sources in starting from commit a9b7b2ad7b075dba5495271706670e5c6b1304bc.  This is part of the QEMU 1.3 (-rc0) release.  The Linux kernel contains the guest driver for the this device since 2.6.26.
Support for the VirtIO RNG device has been added to the QEMU sources starting from commit a9b7b2ad7b075dba5495271706670e5c6b1304bc.  This is part of the QEMU 1.3 release.  The Linux kernel contains the guest driver for the device since version 2.6.26.


== Invocation ==
== Invocation ==

Revision as of 20:30, 10 January 2013

Summary

VirtIO RNG is a paravirtualized device that is exposed as a hardware RNG device to the guest. On the host side, it can be wired up to one of several sources of entropy, including a real hardware RNG device as well as the host's /dev/random if hardware support doesn't exist.

Status

Support for the VirtIO RNG device has been added to the QEMU sources starting from commit a9b7b2ad7b075dba5495271706670e5c6b1304bc. This is part of the QEMU 1.3 release. The Linux kernel contains the guest driver for the device since version 2.6.26.

Invocation

Just adding

-device virtio-rng-pci

to the QEMU invocation will add the device with a default host backend. As of QEMU 1.3, the default backend is to use the host's /dev/random as a source of entropy.

To modify this source to a real hardware RNG on the host, use:

-object rng-random,filename=/dev/hwrng,id=rng0 \
-device virtio-rng-pci,rng=rng0

This passes on any data received from the hardware RNG (via /dev/hwrng) directly to the guest.

Optional parameters to limit the rate of data sent to the guest are inlucded:

-device virtio-rng-pci,max-bytes=1024,period=1000

This restricts the data sent to the guest at 1KB per second. This is useful to not let a guest starve the host of entropy.

Communicating with the EGD Protocol

<fixme>

Testing

On the host

Test if the host device is opened when qemu is started. In the default case, when /dev/random is used, check the output of

lsof /dev/random

Before starting QEMU, the output of the previous command shouldn't show qemu. After starting the guest, the output of the command should show the qemu instance, like:

$ lsof /dev/random
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
qemu-syst 9075 amit   12r   CHR    1,8      0t0 1032 /dev/random

On the guest

Check if the hardware RNG core has detected virtio-rng as a source of entropy:

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

Check what is the current hwrng device in use by the kernel:

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

If the current source is virtio, just reading from the hwrng device will fetch the data from the host:

# cat /dev/hwrng

Without virtio-rng, the /dev/hwrng file won't be available. With virtio-rng, the file will be available, and will show some output. Output may be slow to arrive, as this depends on the amount of entropy the host has to give. Doing mouse, keyboard, network, block activity on the host will accelerate the speed with which the host can give out data to the default /dev/random source.

Next, hook up the virtio-rng hwrng to the guest's entropy pool by running rngd:

# rngd -r /dev/hwrng

Compare the results of

$ cat /dev/random

inside a guest with and without the virtio rng device. The data should flow faster when the virtio rng device is present.

Future work

Intel CPUs will introduce an RDRAND instruction that can give random bytes. This instruction can be directly made available to guests, so the guests won't have to rely on virtio-rng. Also, using RDRAND on the host as a source of entropy to pass on to the guest via virtio-rng is a better way than the current /dev/random source.