Does anybody who is familiar with the BSDs know how those OSes solve this kind of problem? (I don't know enough to say if this even could be a problem with their architecture, just curious).
When the system is brought down cleanly (init 0 or 6) a seed file is saved. Also, when the system is started up, a seed file is created in case there's a crash. OpenBSD's rc(8):
# Push the old seed into the kernel, create a future seed and create a seed
# file for the boot-loader.
random_seed() {
dd if=/var/db/host.random of=/dev/random bs=65536 count=1 status=none
chmod 600 /var/db/host.random
dd if=/dev/random of=/var/db/host.random bs=65536 count=1 status=none
dd if=/dev/random of=/etc/random.seed bs=512 count=1 status=none
chmod 600 /etc/random.seed
}
So the main remaining risk is things like (cloud) images where many people/machines use the same seed. This can be mitigated by stirring in RDRAND, unique CPU information (serial number?), high-res date/time, and other possibly unique information (MAC addresses?).
The Virtio RNG driver was merged into Linux 2.6.26, released a decade ago. AFAIU it should be built into most Linux kernels. I just confirmed on Alpine 3.10 and Ubuntu 18.10 (Cosmic).
The problem is that not all hypervisors provide the device by default. I use libvirt KVM/QEMU and the default template doesn't include it, but you can add it. AWS EC2 doesn't provide it, though it doesn't provide any virtio devices. Parallels Desktop 15 doesn't support virtio-rng, either
OTOH, OpenBSD's VMD not only supports it but I think it's enabled by default. (I see it in the source code. I can't find a way to enable/disable it, but the publicly posted dmesg dumps seem to always show it as found when an OpenBSD guest boots.)
Of course, most VMs are x86_64-based using hardware extensions and likely using CPUs providing rdrand. But hypervisors really should provide the virtio-rng device default, perhaps even unconditionally as OpenBSD apparently does.
It's this kind of problem, but it's not the same problem; the Linux problem under discussion happens at a point during the boot when /var is not yet accessible/writable.