From owner-svn-src-head@freebsd.org Sun Apr 16 12:45:56 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 6AE1BD3F5A3; Sun, 16 Apr 2017 12:45:56 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3A61E1994; Sun, 16 Apr 2017 12:45:56 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1czjYv-00003H-98; Sun, 16 Apr 2017 13:45:54 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r317015 - in head/sys: boot/forth conf crypto/chacha20 dev/random libkern sys From: Mark R V Murray In-Reply-To: <201704161230.v3GCUujl016578@pdx.rh.CN85.dnsmgr.net> Date: Sun, 16 Apr 2017 13:45:52 +0100 Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <201704161230.v3GCUujl016578@pdx.rh.CN85.dnsmgr.net> To: rgrimes@freebsd.org X-Mailer: Apple Mail (2.3273) X-SA-Score: -1.0 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:45:56 -0000 > On 16 Apr 2017, at 13:30, Rodney W. Grimes = wrote: >=20 >> The RC4 algorithm is standard. Making the alogorithm pluggable means = more >> code, more testing and more time (time which I am rather short of). >=20 > I would rather see a proper implementation later, than a poor design > decision today. I would love to see a perfect solution too. As I don't have the time for = it, I took the time to get a working solution reviewed and pretty heavily = tested. Reviewed by SO@, that is. >>> Also you can always compile in a module, you can not compile out >>> a 'standard' file. >>>=20 >>> 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. >>=20 >> It would have to be unconditionally added to *all* kernels. Could be >> done, I guess. >=20 > We dont have that many in base kernel configs do we? No. But what about folks' own configs that break all-of-a-sudden? I've been pretty angry n a few occasions when I'm trying to fix my own = problems and I had to waste time sorting out tangential, avoidable problems. What's the difference between making this 'standard' in sys/files/conf and adding a compulsory change to ALL kernel files (apart from the fact that we miss the users' kernel configs)? We can even keep the module stubs in the code. Later, when/if arc4random(9) becomes a = loadable module (I'd *LOVE* to see how we get that right without compromising the RNG early start), we can make it optional. That is a one line change to sys/conf/files. >> 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. Fix it, sure. What's wrong with doing that as a next step? Why does this change need to be held to ransom? >> Up until now, arc4random worked with unconditional RC4. >=20 > And your wanting to just replace unconditional RC4 for unconditional = chacha? > Or actuall, aleady did? Correct. Both counts. It was up on Phabricator for weeks, BTW. M --=20 Mark R V Murray