urandom by definition doesn't block.

The only time you'd have to worry about this is during boot. Ideally, whatever you're trying to do at boot time should be moved to post-boot time, when the kernel has taken care of all the concerns for you.

I don't know what the answer is to "If you want to generate secure random numbers during boot before urandom is seeded, how would you do it?" I assume it's "Seed urandom, then use it."

> urandom by definition doesn't block.

That's precisely why getrandom(2) is preferred on newer kernels, and the following hacky workaround from the article is given on older kernels:

  For software that runs during the Linux boot, poll /dev/random until it's available.
  This means /dev/urandom has been seeded and you can safely read from /dev/urandom for
  all your cryptographic purposes. Don't read from /dev/random.

I believe it blocks on some BSDs during early boot, when not enough entropy has been collected, maybe OpenBSD?

Not on OpenBSD. The bootloader supplies entropy, so that basically as soon as the kernel starts booting, random numbers are available.

Edit: /dev/random on OpenBSD also does not block.

Thanks for the correction! I didn't know that was possible. It makes sense; it's the only way to ensure urandom is always safe to use.

Does anyone know how other operating systems behave in that situation?