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

[Mark R V Murray]

> On 16 Apr 2017, at 13:07, Rodney W. Grimes <freebsd at pdx.rh.CN85.dnsmgr.net> 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).

> 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.

RC4 has been standard for many years.

>>> 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.

M
-- 
Mark R V Murray