VirtEntropyProvision
Contents
Virtual Machine Entropy Provision
In a bare metal system, an operating system kernel has a number of sources for collecting seed data for their entropy pools eg disks, NICs, mouse movement, interrupts, and more. Most, if not all, of these sources are unavailable to virtual machines, either because they lack the hardware entirely (eg headless with no mouse), or the hardware does not provide satisfactory entropy (virtualized NICs/disk). The result is that virtual machines often have difficulty providing enough entropy to processes they run, especially crypto functions which require entropy from /dev/random rather than /dev/urandom.
The goal of this document is to examine how OpenStack Nova can provide further data to guest operating systems that is suitable for seeding their random entropy pool.
Sources of entropy
Beyond the traditional schemes a Linux kernel uses, there are a number of possible sources of entropy
CPU RNGs
With the IvyBridge line of processors, Intel introduced an on-chip random number generator, accessible via a new RDRAND instruction
The Linux kernel is able to use this instruction to feed its /dev/urandom pool, but will not use it for /dev/random.
The rng-utils package contains the rngd daemon which is also able to make use of this instruction, and after cryptographically validating the quality random numbers, will populate the kernels random pool, making entropy available via /dev/random.
The RDRAND instruction is capable of providing as much as 800 GBytes/second of random data.
TPM RNGs
Trusted Platform Module chips, which are common on many hardware platforms, typically provide an hardware random number generator. On Linux these can be accessed via /dev/tpm device nodes.
The rng-utils package rngd daemon can again obtain data from the TPM RNGs to re-populate the kernel's random pool, making entropy available via /dev/random
Data rates available vary according to the precise hardware in use, so no clear figures are available
Dedicated Hardware RNG devices
There exist various options for external / addon hardware RNG generators. For example, the EntropyKey is a low cost USB based hardware RNG
It comes with software that will feed the random numbers into the kernel's random pool making entropy available via /dev/random
Software entropy gathering
It is possible to provide userspace software packages which gather further entropy based on activity in the OS and feed it into the kernel's random pool. One example is EGD:
The protocol defined by EGD is also implemented by a number of other programs, for compatibility. eg ssh, gpg, qemu.
Another software solution is CSRNG
Providing entropy in guests
There are a number of possible avenues for providing entropy in guests, with varying characteristics
Paravirtualized device
Linux contains a paravirtualized hardware RNG device, known as virtio-rng which is able to seed the kernel's random pool,making entropy available via /dev/random. The QEMU/KVM backend for this device is able to feed it with entropy from the host's /dev/random device, or from a daemon supporting the EGD protocol. QEMU will optionally rate limit the data that the guest can request, to prevent a single guest from exhausting the host's entropy supply.
If QEMU's built-in rate limiting policy is not sufficient, it is a simple matter to create a custom daemon supporting the EGD protocol that controls the flow of entropy to guests based on arbitrary application defined metrics
Although no implementation currently exists, it would also be possible to provide a virtualized TPM device to feed random entropy to the guest.
CPU RNG
As mentioned earlier, the IvyBridge CPUs from Intel provide a hardware RNG. Use of this feature is not restricted to host OS only. Guest virtual machine instances can also use the RDRAND instruction to obtain entropy directly.
As before the rng-utils package contains the rngd daemon which is also able to make use of this instruction, and after cryptographically validating the quality random numbers, will populate the kernels random pool, making entropy available via /dev/random.
Software entropy gathering
Of course any of the pure software entropy gathering daemons mentioned earlier can be run in the guest, just as they are in the host. That said, depending on the techniques they use for gathering entropy, the quality of their output may be compromised when run inside a guest.
Config drive
Nova has the ability to provide arbitrary metadata to guest OS, using the "config drive" feature. This creates an ISO image on guest boot up containing metadata files. It is possible to provide a block of entropy to the guest via this image. Assuming it has satisfactory quality, this could be used to seed the kernel's random number pool, making entropy available via /dev/random
Metadata service
As an alternative to the config drive, Nova also supports a metadata service which a guest can access over a private host<->guest network link. It provides the same metadata as the config drive, but with the difference that the data can be refreshed at any time. This can be leveraged to allow arbitrary amounts of entropy to be made available to the guest while it is running.
