Skip to main content

SCS Entropy


Entropy in information technology

Entropy is a concept that is widely used in the scope of information technology. It is a measurement of the amount of disorder or randomness in a system. Entropy is used to measure the amount of information in a self-contained system, as well as the amount of incertitude that exists in this system.

Real-world uses of entropy

Cryptography is a very prominent, albeit not the only application that heavily relies on entropy for operations such as creating secure keys. When the available entropy runs out, said operations can stall and take an abnormally long amount of time, which in turn can lead to malfunctions, e.g., with OpenSSL or load balancers.

Sources of entropy

In traditional baremetal systems the amount of incertitude is sourced from the randomness of the read/write cycles of the disk heads of a disk drive, bus timings, or keyboard timings, to name a few.

More recent methods of generating entropy include measuring IRQ jitter (available in Linux since kernel 5.4 or, before that, via a daemon such as HavegeD) as well as dedicated CPU instructions (available in virtually all major CPUs: RDSEED or RDRAND on x86_64 and RNDR on arm64).

Finally, a dedicated device can be utilized — if present — that is called hardware random number generator or HRNG for short. For instance, the Trusted Platform Module includes a HRNG. On Linux systems, the HRNG appears as /dev/hwrng. Note that, while the dedicated CPU instructions can be construed as a HRNG, they are not treated as such by the kernel, i.e., they do not appear as /dev/hwrng!

The Linux kernel combines multiple sources of entropy into a pool. To this end, it will use all the sources discussed so far with one exception: the HRNG must be fed into the pool (if so desired) via the daemon rngd. The kernel converts the entropy from the pool into cryptographically secure random numbers that appear under /dev/random and /dev/urandom.

With kernel 5.18, the algorithm that accomplishes said conversion has been drastically improved (see linux-rng-5.17-18), so much so that running out of entropy is virtually ruled out. These patches have now also arrived in the upstream LTS images.

Entropy in virtual instances

Virtual instances or virtual machines do not have the traditional sources of entropy mentioned above. However, the more recent methods mentioned above do work just fine (the CPU instructions are not privileged).

Alternatively, a virtualized HRNG called virtio-rng can be established that injects entropy from the host into the instance, where this entropy can be sourced optionally from either the host's /dev/random or some HRNG in the host. This virtualized HRNG behaves just like a real one, that is, it appears as /dev/hwrng, and the daemon rngd must be used to feed it into the kernel's entropy pool.

On a side note, the kernel exposes available HRNGs via the special directory /sys/devices/virtual/misc/hw_random. In particular, the file rng_available lists available HRNGs while the file rng_current contains the HRNG currently used.

In summary, with current kernels and CPUs entropy in virtual instances is readily available to a sufficient degree. In addition, the host's entropy sources can be injected using virtio-rng if so desired, e.g., to enable access to a HRNG.


As stated above, good sources of entropy are paramount for many important applications. This standard ensures that sufficient entropy will be available in virtual instances.

Entropy in SCS clouds


It is recommended that all flavors have the following attribute:


The following attributes are optional:

hw_rng:rate_bytes - The allowed amount of bytes for the the guest
to read from the host's entropy per period.
hw_rng:rate_period - Sets the duration of a read period in seconds.


It is recommended to use images having a kernel (patch level) version 5.18 or up. This condition is already satisfied by every mandatory image defined in the Image Metadata Standard.

It is recommended that images activate the attribute hw_rng_model: virtio.

The daemon rngd must be installed (usually from rng-tools or rng-utils).

The user may choose to use the virtio-rng device via rngd.

Compute nodes

Compute nodes must use CPUs that offer instructions for accessing entropy (such as RDSEED or RDRAND on x86_64 or RNDR on arm64), and these instructions may not be filtered by the hypervisor.

Compute nodes may provide a HRNG via rngd.