tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: /dev/random is hot garbage



> On Sun, Jul 21, 2019 at 04:53:08PM +0000, Taylor R Campbell wrote:
>>   It has become popular to redefine the traditional semantics of
>>   /dev/random or /dev/urandom so that one or both will block once at
>>   boot until the OS thinks the entropy pool may have been seeded, and
>>   then never block again.

Right, I get the impression this is what FreeBSD does.

BTW, you are all of course aware of

  https://www.2uo.de/myths-about-urandom

which provides a good discussion about many of these issues, but
perhaps with most of the focus on the myth of /dev/random somehow
providing "better" randomness than /dev/urandom (I didn't see this
reference mentioned earlier in the discussion, and thought it might be
relevant).  Now, I'm sure some of the nitty-gritty details of how
/dev/random and /dev/urandom is in NetBSD is slightly different from
Linux -- perhaps someone more familiar with the finer details may
speak up if there are any significant differences.

>>   I don't want to do this because code paths that may block but only
>>   in extreme circumstances, like early at boot on an embedded system,
>>   are likely never to be exercised even during what might otherwise be
>>   extensive testing, and as noted blocking when not expected can have
>>   severe consequences.

I'm not sure I agree with this argument, especially as long as
the silliness with continuing to insist on using /dev/random for
"better" random numbers is well and alive, or even as the case
with rust's "rnd" library insisting on taking on the role of what
should arguably be the system's responsibility (ensuring the
system's randomness system has been primed).

> It currently blocks for literally hours/days.

I agree this is not good.  Until Xen is fitted with some device for
randomness, I think I'd as system administrator pick the "symlink
/dev/random to /dev/urandom" approach, perhaps also turning on net and
disk as randomness sources, and also have something in the system
startup which ensures /dev/random is properly seeded.

Regards,

- Håvard


Home | Main Index | Thread Index | Old Index