From owner-svn-src-head@freebsd.org Sun Apr 16 12:30:58 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39FEAD3F148; Sun, 16 Apr 2017 12:30:58 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E176F10A7; Sun, 16 Apr 2017 12:30:57 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v3GCUulQ016579; Sun, 16 Apr 2017 05:30:56 -0700 (PDT) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v3GCUujl016578; Sun, 16 Apr 2017 05:30:56 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201704161230.v3GCUujl016578@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r317015 - in head/sys: boot/forth conf crypto/chacha20 dev/random libkern sys In-Reply-To: <60A59E27-47CD-4552-8265-0E60C09E1966@FreeBSD.org> To: Mark R V Murray Date: Sun, 16 Apr 2017 05:30:56 -0700 (PDT) CC: rgrimes@freebsd.org, src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 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: Sun, 16 Apr 2017 12:30:58 -0000 > > > On 16 Apr 2017, at 13:07, Rodney W. Grimes wrote: > > > >>> From replacing the rc4 algorithm with chacha20, this chalice has now > >> become poisoned with the job of redesigning the entire structure of > >> kernel random-number generation. > >> > >> This may take a while, and I'm already behind on RNG jobs. > > > > I do not see how this is a complete redesign of RNG, and if it is > > such a heart ache to change algorithms in this code then it probably > > should be redesigned? > > The RC4 algorithm is standard. Making the alogorithm pluggable means more > code, more testing and more time (time which I am rather short of). I would rather see a proper implementation later, than a poor design decision today. > > Also you can always compile in a module, you can not compile out > > a 'standard' file. > > > > For now could you just add > > options chacha #Required by arc4random, do not remove > > to your kernel and move on? For me this would be an acceptable > > developement, even releasable, way to proceed while the more > > complex issue of how to make the kernel RNG use plagable lkm > > lower layers. > > It would have to be unconditionally added to *all* kernels. Could be > done, I guess. We dont have that many in base kernel configs do we? > RC4 has been standard for many years. Probably another rapid mode of design rather than a thoughful mode, we have a chance to correct this here, and imho, should. > >>> I am sure with careful though we can find a way to allow arc4random > >>> to use a pointer that knows if the chacha code is avaliable, and use > >>> it if so, and if not fall back to something else, or punt with an > >>> error return. > >> > >> Error return is out of the question; arc4random() is pretty fundamental. > >> The alternative is to return no or fake random numbers, which rather > >> misses the point of what this is for. But it can be done. > > > > Arc4random works today without chacha, why would adding support for chache > > as an optional loadable function break that? *truely confused* > > Up until now, arc4random worked with unconditional RC4. And your wanting to just replace unconditional RC4 for unconditional chacha? Or actuall, aleady did? -- Rod Grimes rgrimes@freebsd.org