Features/VirtIORNG: Difference between revisions
(Add feature page for virtio rng device) |
m (Add (empty) section on egd) |
||
Line 27: | Line 27: | ||
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. | 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 == | == Testing == |
Revision as of 18:44, 28 November 2012
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 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.
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.