From owner-svn-src-head@FreeBSD.ORG Thu Aug 1 08:35:02 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2D81D811; Thu, 1 Aug 2013 08:35:02 +0000 (UTC) (envelope-from philip@rincewind.paeps.cx) Received: from rincewind.paeps.cx (rincewind.paeps.cx [IPv6:2a01:4f8:162:1261::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AD07521F3; Thu, 1 Aug 2013 08:35:01 +0000 (UTC) Received: by rincewind.paeps.cx (Postfix, from userid 1001) id 069B511E6; Thu, 1 Aug 2013 10:34:59 +0200 (CEST) Date: Thu, 1 Aug 2013 10:34:59 +0200 From: Philip Paeps To: Adrian Chadd 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: <20130801083459.GI59509@rincewind.paeps.cx> Mail-Followup-To: Adrian Chadd , "David E. O'Brien" , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201307292026.r6TKQRRb021717@svn.freebsd.org> <20130731104009.GG59509@rincewind.paeps.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-PGP-Fingerprint: 356B AE02 4763 F739 2FA2 E438 2649 E628 C5D3 4D05 X-Date: Today is Pungenday, the 67th day of Confusion in the YOLD 3179 X-Phase-of-Moon: The Moon is Waning Crescent (26% 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, "David E. O'Brien" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 08:35:02 -0000 On 2013-07-31 11:15:55 (-0700), Adrian Chadd wrote: > On 31 July 2013 03:40, Philip Paeps wrote: > >> * 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. > > I'm 100% against this. I'm getting extremely fed up with the "default > is on" bloat that is everywhere in our sub-systems. David is actually > _tidying things up_ by making optional devices be standalone devices - > that way they show up as very simple to include and expand when making > modules of things. Otherwise you turn this into a single, monolithic > module that has compile options.. and that sucks. I'm absolutely not against "removing bloat" in general. This particular change, however, potentially leaves anyone who builds a custom kernel ("to remove bloat") and doesn't have a hardware PRNG without any PRNG. We don't make changes like that without warning people. While everyone should read UPDATING, many people only read it when stuff (visibly) breaks, which could cause this change to slip under the radar for them. > David's way is clean, simple and architecturally well-designed. It's > how it should've been done in the first place. Sure. I agree. I read through the random_adaptors code and I like the design and couldn't see any immediate issues. The reasons I wanted this backed out for now, are firstly that we have a policy that changes affecting random should be reviewed by secteam before being committed and secondly that I don't feel we should potentially be leaving a large group of people without any functional random. As soon as secteam can do a more thorough review of the random_adaptors code, it should definitely come back. It's an architectural change in the right direction. I am a lot less sure about removing Yarrow by default, but that's something we can discuss as a separate issue - it doesn't block the architectural improvement as far as I'm concerned. > > I'd really like to see this get some more review. > > I'd like to see the architectural changes needed for a cleanup like > this take place, rather than getting lost in discussion. I think we are enthusiastically agreeing with each other for the most part. :) I also want the architectural improvement and I'm all in favour of removing bloat. > For the MIPS boards I hack on/for, I don't have any guaranteed random > number generator. So it's Yarrow or bust. So we need to "properly > seed" things as best as we can before any hardware random number > generators are loaded. The same problem exists for i386/amd64 with > hardware PRNGs.. we should ensure yarrow is properly seeded here. Right. And had you not seen this discussion, when would you have noticed that Yarrow was gone? How long would you have run with poor random before you found the entry in UPDATING that told you that you needed to add an option to your kernel configuration? I agree that this change is generally good. I just want to see it more thoroughly reviewed by secteam, and a discussion about whether we want Yarrow to be default, and if not, when we throw that switch. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information