Linux Kernel Entropy Pool
Today’s computer systems require random number generators for numerous cryptographic and other purposes. 
On Linux systems, the kernel’s entropy pool is typically used as high-quality source of random numbers. 
The kernel’s entropy pool combines various entropy inputs together, mixes them and provides an API to 
userspace as well as to internal kernel subsystems to retrieve it. This entropy pool needs to be initialized
with a minimal level of entropy before it can provide high quality, cryptographic random numbers to applications.
Until the entropy pool is fully initialized application requests for high-quality random numbers cannot be fulfilled.

The Linux kernel provides three relevant userspace APIs to request random data from the kernel’s entropy pool:

The getrandom() system call with its flags parameter set to 0. If invoked the calling program will synchronously 
block until the random pool is fully initialized and the requested bytes can be provided.

The getrandom() system call with its flags parameter set to GRND_NONBLOCK. If invoked the request for random bytes
will fail if the pool is not initialized yet.

Reading from the /dev/urandom pseudo-device will always return random bytes immediately, even if the pool is not
initialized. The provided random bytes will be of low quality in this case however. Moreover the kernel will log
about all programs using this interface in this state, and which thus potentially rely on an uninitialized entropy pool.

(Strictly speaking there are more APIs, for example /dev/random, but these should not be used by almost any 
application and hence aren’t mentioned here.)

Note that the time it takes to initialize the random pool may differ between systems. If local hardware random
number generators are available, initialization is likely quick, but particularly in embedded and virtualized
environments available entropy is small and thus random pool initialization might take a long time (up to tens of minutes!).

Modern hardware tends to come with a number of hardware random number generators (hwrng), that may be used
to relatively quickly fill up the entropy pool. Specifically:

All recent Intel and AMD CPUs provide the CPU opcode RDRAND to acquire random bytes. Linux includes random
bytes generated this way in its entropy pool, but didn’t use to credit entropy for it (i.e. data from this
source wasn’t considered good enough to consider the entropy pool properly filled even though it was used). 
This has changed recently however, and most big distributions have turned on the CONFIG_RANDOM_TRUST_CPU=y
kernel compile time option. This means systems with CPUs supporting this opcode will be able to very quickly
reach the “pool filled” state.

The TPM security chip that is available on all modern desktop systems has a hwrng. It is also fed into the
entropy pool, but generally not credited entropy. You may use rng_core.default_quality=1000 on the kernel
command line to change that, but note that this is a global setting affect all hwrngs. (Yeah, that’s weird.)

Many Intel and AMD chipsets have hwrng chips. Their Linux drivers usually don’t credit entropy. (But there’s
rng_core.default_quality=1000, see above.)

Various embedded boards have hwrng chips. Some drivers automatically credit entropy, others do not. Some WiFi
chips appear to have hwrng sources too, and they usually do not credit entropy for them.

virtio-rng is used in virtualized environments and retrieves random data from the VM host. It credits full entropy.

The EFI firmware typically provides a RNG API. When transitioning from UEFI to kernel mode Linux will query
some random data through it, and feed it into the pool, but not credit entropy to it. What kind of random source
is behind the EFI RNG API is often not entirely clear, but it hopefully is some kind of hardware source.

If neither of these are available (in fact, even if they are), Linux generates entropy from various non-hwrng
sources in various subsystems, all of which ultimately are rooted in IRQ noise, a very “slow” source of entropy, 
in particular in virtualized environments.

        random.trust_cpu={on,off}
                        [KNL] Enable or disable trusting the use of the
                        CPU's random number generator (if available) to
                        fully seed the kernel's CRNG. Default is controlled
                        by CONFIG_RANDOM_TRUST_CPU.

[    0.001000] random: get_random_bytes called from start_kernel+0x36b/0x55b with crng_init=0
[    1.053467] random: systemd: uninitialized urandom read (16 bytes read)
[    1.053607] random: systemd: uninitialized urandom read (16 bytes read)
[    1.053769] random: systemd: uninitialized urandom read (16 bytes read)
[    2.843114] random: crng init done

[    0.001000] random: crng done (trusting CPU's manufacturer)

func warnBlocked() {
	println("crypto/rand: blocked for 60 seconds waiting to read random data from the kernel")
}

func (r *devReader) Read(b []byte) (n int, err error) {
	if atomic.CompareAndSwapInt32(&r.used, 0, 1) {
		// First use of randomness. Start timer to warn about
		// being blocked on entropy not being available.
		t := time.AfterFunc(60*time.Second, warnBlocked)
		defer t.Stop()
	}
	if altGetRandom != nil && r.name == urandomDevice && altGetRandom(b) {
		return len(b), nil
	}
	r.mu.Lock()
	defer r.mu.Unlock()
	if r.f == nil {
		f, err := os.Open(r.name)
		if f == nil {
			return 0, err
		}
		if runtime.GOOS == "plan9" {
			r.f = f
		} else {
			r.f = bufio.NewReader(hideAgainReader{f})
		}
	}
	return r.f.Read(b)
}