4 ms·
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
by sillysaurus3 10y ago
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."
- heinrich5991 10y agoI believe it blocks on some BSDs during early boot, when not enough entropy has been collected, maybe OpenBSD?
- sillysaurus3 10y agoThanks 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?
- ben_bai 10y agoNot 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.
- CiPHPerCoder 10y ago> 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.