svn commit: r317015 - in head/sys: boot/forth conf crypto/chacha20 dev/random libkern sys

Rodney W. Grimes freebsd at pdx.rh.CN85.dnsmgr.net
Sun Apr 16 12:07:37 UTC 2017


> 
> > On 16 Apr 2017, at 12:50, Rodney W. Grimes <freebsd at 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 at freebsd.org


More information about the svn-src-head mailing list