Date: Wed, 31 Jul 2013 12:40:09 +0200 From: Philip Paeps <philip@freebsd.org> To: "David E. O'Brien" <obrien@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r253779 - in head: . share/man/man4 sys/amd64/conf sys/arm/conf sys/conf sys/dev/random sys/i386/conf sys/ia64/conf sys/mips/conf sys/modules sys/modules/random sys/pc98/conf sys/powerp... Message-ID: <20130731104009.GG59509@rincewind.paeps.cx> In-Reply-To: <201307292026.r6TKQRRb021717@svn.freebsd.org> References: <201307292026.r6TKQRRb021717@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2013-07-29 20:26:27 (+0000), David E. O'Brien <obrien@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130731104009.GG59509>