[geofft]

One of the very early initscripts (on Debian, /etc/rcS.d/urandom or /lib/systemd/system/urandom.service, both of which happen well before normal initscripts) restores a random seed that was saved at last shutdown.

After this script runs, the numbers are back to being cryptographically pseudorandom. Before this script runs, lots of other stuff isn't set up -- no networking, no remote filesystems, possibly not even swap -- so if you're writing code that needs to run there, you hopefully know that the system is in a weird state. And if you're writing something that runs a service that needs secure random numbers that early in the boot process, you're definitely doing something nonstandard and possibly misguided, and it's reasonable for the burden to be on you to take appropriate precautions, or switch to doing something normal.

For normal application developers, who tend to wait until after the network is up to interact with the network, this special case doesn't apply.

[slavik81]

The usual time I've been concerned has been after creating a new virtual machine. Right after creating a new DO droplet I need to do a bunch of things to set up my application, like seed my CSRF token generator.

Of course, /dev/random would block for ages at that point, so I instead generate the seed on a different machine.

[geofft]

Ugh, yes, the practice of short-lived machines throws off the assumption of "when it was last shut down." You are totally right that this is a concern.

The ideal solution to this would be for hypervisors to just pass a random seed to their guests. (There is even a full virtio-rng device in qemu, it just seems to have /dev/random semantics from a quick glance.) I don't know how we get to the point of convincing the big cloud providers to start doing this, though.

[jasonvorhe]

Wouldn't it help to run something like havaged on the virtualization host that's feeding entropy to the virtualized nodes?

[jquast]

yes