Random seed not propagating to the entropy pools in a timely manner

Question

The Linux kernel's randomness driver collects entropy from the environment. Because there will be little entropy during boot, a random seed is often kept at /var/lib/misc/random-seed or a similar location. When the system shuts down, a new 512-byte random seed is written to this file. When the system boots up, this file is written to /dev/urandom, which adds it to the entropy pool. The point is to allow the state of the entropy pool to persist across reboots. There are issues:

1. Data written to the nonblocking pool gets first put in the input pool, and it will only be usable after enough entropy is collected for a "catastrophic reseed". This means that it may take a few minutes for the entropy in the random seed to actually affect the CSPRNG.

2. For the same reason, if the system boots up and then shuts down within a few minutes, the new seed that is written will not have entropy from the previous seed, making it far easier to predict. This is likely an issue for systems that may have very low uptime, as it means that they will effectively reset their persistent entropy seed fairly often.

Is my analysis correct? What are the real-world implications of these issues? For example, are there any systems in common use (especially embedded systems) which either require unpredictable randomness within a few minutes of reboot, or which may have very short uptime?

---

In the kernel's randomness driver, writing to either the blocking or nonblocking pools triggers the random_write() operation and inside it, write_pool() with the input pool specified as the argument. The input pool is periodically used to reseed the blocking pool via the push_to_pool() workqueue function. The nonblocking pool will reseed itself from the input pool every 5 minutes when _extract_crng() is called to extract data from the nonblocking pool (assuming at least 128 bits of entropy have been added to the input pool since the last reseed). This flow of information implies that the random seed stored across reboots will only affect the contents of the blocking pool after a (64-bit) catastrophic reseed, and the nonblocking CRNG every 5 minutes.

Answer 1

There are some assumptions I must question:

A. “Because there will be little entropy during boot”.

B. “The point is to allow the state of the entropy pool to persist across reboots”

Addressing A: While it is possible that specific system configuration you happen to use experiences low entropy issues, this is not a typical occurrence. However, “Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices” by N. Heninger describes such condition in headless systems. For this condition to happen multiple entropy sources must be absent or operate at degraded performance. First, it must be a headless system, so there is no entropy from add_input_randomness(). Second, must be very limited controller activity, and this includes network card, so there is little interrupts driving add_interrupt_randomness(). Third, there must be no block device (e.g. hard disk), so add_disk_randomness() doesn’t generate entropy. For example, modern SATA3 SSD will generate about 200 bits of entropy by itself during boot via add_disk_randomness().

Addressing B: Saving entropy pool state is an incomplete solution to a serious problem. If you have low boot time entropy, then that is the key problem you should focus on. If you also frequently reboot such problem becomes catastrophic. Improving saved entropy design will not resolve the underlying problem of lack of entropy.