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

[Mark R V Murray]

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

M
-- 
Mark R V Murray