4 ms·
I've seen you post that a few times, so two minor nitpicks. In the mental model in which the /dev/random manpage lives, it makes (some) sense to read /dev/rand
by JoachimSchipper 10y ago
I've seen you post that a few times, so two minor nitpicks.
In the mental model in which the /dev/random manpage lives, it makes (some) sense to read /dev/random until you get a short read, then make a userland pool from all the data you've read, "to get as much entropy as possible". That reasoning doesn't actually make sense, of course, but I would be surprised if nobody thought that such a construction would be a good idea.
Separately, there's quite a lot of code - and I've written some - that reads a byte from /dev/random at daemon start, specifically to block until the system has built up enough entropy. FreeBSD blocks reads, even from /dev/urandom, until the [EDIT: estimate of how much entropy has ever gone into the pool] gets high enough, which makes some sense; but there needs to be some way to block-until-random.
- tptacek 10y agoFreeBSD blocks until the generator is seeded. I think Linux urandom should do the same thing. But once it's seeded, there is no reason for the generator ever to block again.
- JoachimSchipper 10y agoYes, that's what I meant. Edited for clarity, thanks!
- mioelnir 10y agoOn 11.x random routinely unblocks before the userland is even started, so from an application standpoint random really never blocks.