> 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
