Date: Sun, 16 Apr 2017 05:07:36 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> To: Mark R V Murray <markm@FreeBSD.org> Cc: rgrimes@FreeBSD.org, src-committers <src-committers@FreeBSD.org>, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Subject: Re: svn commit: r317015 - in head/sys: boot/forth conf crypto/chacha20 dev/random libkern sys Message-ID: <201704161207.v3GC7adp016485@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <8814F883-F255-45E4-8FFE-254359B51B38@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > On 16 Apr 2017, at 12:50, Rodney W. Grimes <freebsd@pdx.rh.CN85.dnsmgr.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201704161207.v3GC7adp016485>