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:
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.
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.