On 2013-07-29 20:26:27 (+0000), David E. O'Brien <obr...@freebsd.org> wrote: > Author: obrien > Date: Mon Jul 29 20:26:27 2013 > New Revision: 253779 > URL: http://svnweb.freebsd.org/changeset/base/253779 > > Log: > Decouple yarrow from random(4) device.
As Dag-Erling already pointed out in relpy to r253789: please submit any RNG changes to secteam@ to review before committing them. That aside, it would have been easier to review this if it were split into more than two commits. > * Make Yarrow an optional kernel component -- enabled by "YARROW_RNG" > option. > The files sha2.c, hash.c, randomdev_soft.c and yarrow.c comprise yarrow. I would really prefer to see this logic reversed. Of course, we expect people to read UPDATING, but disabling functionality that has been enabled by default "forever" without any warning, especially in a security-related context is not cool. Please change YARROW_RNG to RNG_NO_YARROW or something similar and keep it in by default. If you think there's a really good reason to kick support out by default, there are mailing lists to discuss this. > * Add random_adaptors.[ch] which is basically a store of random_adaptor's. > random_adaptor is basically an adapter that plugs in to random(4). This is a good idea. I've briefly read through the code (ie: not a thorough review) and it looks okay at first glance. It would have been good if this were a separate commit and given a chance to be reviewed by people familiar with the RNG code. > Unplugging random_adaptor from random(4) is not supported, and is > probably a > bad idea anyway, due to potential loss of entropy pools. I agree. But what happens to the adaptors if you kldunload random? > * If the kernel doesn't have any random_adaptor adapters present then the > creation of /dev/random is postponed until next random_adaptor is > kldload'ed. This worries me. A fast-booting system might want random numbers in userland before a random_adaptor is loaded (and properly seeded?). We don't have particularly stellar support for early random numbers, but we should be careful not to make it worse. Also: what happens to in-kernel consumers of random (like TCP) before the first random_adaptor is attached (and properly seeded)? I'd really like to see this get some more review. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"