From owner-svn-src-all@FreeBSD.ORG Wed Jul 31 10:40:12 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 40E93B45; Wed, 31 Jul 2013 10:40:12 +0000 (UTC) (envelope-from philip@rincewind.paeps.cx) Received: from rincewind.paeps.cx (rincewind.paeps.cx [5.9.88.46]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EFC532A27; Wed, 31 Jul 2013 10:40:11 +0000 (UTC) Received: by rincewind.paeps.cx (Postfix, from userid 1001) id 76284129D; Wed, 31 Jul 2013 12:40:09 +0200 (CEST) Date: Wed, 31 Jul 2013 12:40:09 +0200 From: Philip Paeps To: "David E. O'Brien" 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> Mail-Followup-To: "David E. O'Brien" , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201307292026.r6TKQRRb021717@svn.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201307292026.r6TKQRRb021717@svn.freebsd.org> X-PGP-Fingerprint: 356B AE02 4763 F739 2FA2 E438 2649 E628 C5D3 4D05 X-Date: Today is Boomtime, the 66th day of Confusion in the YOLD 3179 X-Phase-of-Moon: The Moon is Waning Crescent (34% of Full) X-Philip-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 10:40:12 -0000 On 2013-07-29 20:26:27 (+0000), David E. O'Brien 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