Features/VirtIORNG

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.

Effect of the period parameter

(by Amos Kong <akong@redhat.com>)
When we set a fixed rate speed, we can use different periods. The
period still effect the stable of system IO.
If the period is too large, and we set a higher speed, then IO will wave.

Example:  the IO max speed is 20 M/s, and we test 5 mins
          it clear that the first period is better

_Theory_ Condition:

* period 1:   20M / 1s
  from 0 ~ 20 second, read packets,
  from 21 ~ 100 second, wait ...

  from 0 ~ 20 second, read packets,
  from 21 ~ 100 second, wait ...

  from 260 ~ 281 second, read packets,
  from 281 ~ 300 second, wait ...

* period 2:   100M / 5
  from 0 ~ 60 second, read packets,
  from 61 ~ 300 second, wait ...

Smaller period is better, but smaller period will cause more timer
expired, and IO wave will be balance by scheduling other process.

Communicating with the EGD Protocol

 # ./readbytes (listen 1024 port, read data from some source, and send to remote client socket)

 # qemu-kvm ...... \
 -chardev socket,host=10.66.4.212,port=1024,id=chr0 \
 -object rng-egd,chardev=chr0,id=rng0 \
 -device virtio-rng-pci,rng=rng0

usage of real rng device(QNG PQ4000KU)

Config the real rng device(QNG PQ4000KU), read data from the device by libqwqng API. Transfer data to qemu (w/ virt-rng EGD backend) by a socket.

More detail: real rng device

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. However, announcing the availability of the RDRAND instruction on the host may not be desirable due to live migration constraints. Using RDRAND on the host, if available, as a source of entropy to pass on to the guest via virtio-rng is better than the current /dev/random source. The RDSEED instruction, in a future Intel processor, will output real entropy (instead of just random numbers that the RDRAND outputs). Using RDSEED as a source is equivalent to using a real hardware rng. This has the advantage of not depleting the host's entropy pool, as well as passing real entropy to the guest instead of CSPRNG.

The performance rng-egd backend is very bad, the request queue doesn't work actually. Another request will come when the first request is processed by chr_read(). I have a solution to improve the performance, we can use a cache queue to pre-read randome data, when request is coming, it give quick feedback if the data is prepared. We can use the space time to fill the cache queue. In my testing, the read speed can be improved from 0.9k/s to 500k/s

More Information

There is some more information on this feature, and testing instructions at these links:

• Amit Shah's blog post
• Fedora Feature Page
• Fedora QA Testcase Page