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

[Rodney W. Grimes]

> > On 16 Apr 2017, at 13:30, Rodney W. Grimes <freebsd at pdx.rh.CN85.dnsmgr.net> wrote:
> > 
> >> The RC4 algorithm is standard. Making the alogorithm pluggable means more
> >> code, more testing and more time (time which I am rather short of).
> > 
> > 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.
> >>> 
> >>> 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.
> > 
> > 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.

Fair point.  I have spent the last 4 months dealing with what are the
un portability of the human to a new version of FreeBSD due to breakage
and changes in the new version, not to mention all the new features
that broke old behavior in sometimes very subtle ways.

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

Later never seems to happen.... thats why I am trying to push for stopping
the later mode of operation and pushing the if we are going to change things
we should be changing them in the right and for the better and stop rushing
so we can only do it over again later.

As far as getting things right at boot time, thats trivial, the module
*can* be loaded by the loader afterall, this is not new science.

We have similiar with ZFS, you have to load that with your kernel if you
are booting with zfs root, correct?

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

Thats a fair point, let me counter, why do I want this change at all?
Is it just the new kid on the block and everyone wants to play with the
new toy, or does it bring the users some wonderful star bright feature
that they just can not live without?  Is arc4random(9) some how fundementaly
broken without chacha?

Your code in and working now? 
We just have 2 implementations of chacha, correct?
One in your static compiled in kernel section, and one as an LKM?

> >> Up until now, arc4random worked with unconditional RC4.
> > 
> > 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.

We are having what I believe is a very serious disjoint in project communications
caused by phabricator.  How are the developers notified of new things going
up in phabricator?  I get bugzilla reports, but I get zip from phabriactor unless
I go ask it for stuff.   I get #network stuff cause I saw that in a commit that
I would of liked to been aware of early and added into that project, but overall
I think we need to work on this communcations too.

-- 
Rod Grimes                                                 rgrimes at freebsd.org