locks and kernel randomness...

[Pawel Jakub Dawidek]

On Tue, Feb 24, 2015 at 11:03:42AM -0700, Warner Losh wrote:
> 
> > On Feb 24, 2015, at 10:40 AM, John-Mark Gurney <jmg at funkthat.com> wrote:
> > 
> > Warner Losh wrote this message on Tue, Feb 24, 2015 at 07:56 -0700:
> >> Then again, if you want to change random(), provide a weak_random() that???s
> >> the traditional non-crypto thing that???s fast and lockless. That would make it easy
> >> to audit in our tree. The scheduler doesn???t need cryptographic randomness, it
> >> just needs to make different choices sometimes to ensure its notion of fairness.
> > 
> > I do not support having a weak_random...  If the consumer is sure
> > enough that you don't need a secure random, then they can pick an LCG
> > and implement it themselves and deal (or not) w/ the locking issues...
> > 
> > It appears that the scheduler had an LCG but for some reason the authors
> > didn't feel like using it here..
> 
> Why don’t you support having a common random routine that’s to mix the
> pot, but not cryptographically secure? Lots of algorithms use them, and having
> a common one would keep us from reinventing the wheel.

Sorry for being late to the party:)

I'm with John-Mark on this one. I didn't find it being mentioned in the
thread, but the more consumers we have of our CSPRNG the better. It
makes it less predictable in case of a weekness in the algorithm /
implementation / entropy sources.

Because of that I'd much rather have the rule that if you don't want to
use CSPRNG you need to prove that it is both not required and degrades
performance.

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://mobter.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20150516/2a260385/attachment.sig>