From owner-svn-src-head@freebsd.org Sun Apr 16 12:07:37 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 D692BD41A6E; Sun, 16 Apr 2017 12:07:37 +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 A1E80329; Sun, 16 Apr 2017 12:07:37 +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 v3GC7aqW016486; Sun, 16 Apr 2017 05:07:36 -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 v3GC7adp016485; Sun, 16 Apr 2017 05:07:36 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201704161207.v3GC7adp016485@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: <8814F883-F255-45E4-8FFE-254359B51B38@FreeBSD.org> To: Mark R V Murray Date: Sun, 16 Apr 2017 05:07:36 -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:07:37 -0000 > > > On 16 Apr 2017, at 12:50, Rodney W. Grimes wrote: > > > >> This does not use DES' Chacha20 commit, as I had already completed the > >> testing for it, and received SO@ approval. > >> > >> DES's commit made Chaha20 a module. This is of no use to arc4random(9), > >> which needs the code to be standard. Also his API is different. > >> > >> I have no objection to reworking the arc4random/Chacha below to use DES' > >> version of Chacha, but his code needs to be standard library code, > >> not an optional module. > >> > >> Any objections to me doing this? > > > > Yes > > > > We need to move towards more modules, not less. Having this standard > > does not even allow one to compile a kernel without it. I should be > > able to compile a kernel without arc4random(9) and without chacha if > > I so desire. And I should be able to load and unload these if I so > > desire. This later feature is VERY usefull for developement and > > debug cycles. > > >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? 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. > > 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* -- Rod Grimes rgrimes@freebsd.org