Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Feb 2015 12:05:22 -0700
From:      Ian Lepore <ian@freebsd.org>
To:        John-Mark Gurney <jmg@funkthat.com>
Cc:        Konstantin Belousov <kostikbel@gmail.com>, Harrison Grundy <harrison.grundy@astrodoggroup.com>, freebsd-arch@freebsd.org
Subject:   Re: locks and kernel randomness...
Message-ID:  <1424804722.3293.12.camel@freebsd.org>
In-Reply-To: <20150224183051.GJ46794@funkthat.com>
References:  <20150224012026.GY46794@funkthat.com> <20150224015721.GT74514@kib.kiev.ua> <54EBDC1C.3060007@astrodoggroup.com> <20150224024250.GV74514@kib.kiev.ua> <DD06E2EA-68D6-43D7-AA17-FB230750E55A@bsdimp.com> <20150224174053.GG46794@funkthat.com> <1E4A5E62-6E06-48BA-B5C5-9BD05811CDEF@bsdimp.com> <20150224183051.GJ46794@funkthat.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2015-02-24 at 10:30 -0800, John-Mark Gurney wrote:
> Warner Losh wrote this message on Tue, Feb 24, 2015 at 11:03 -0700:
> > 
> > > On Feb 24, 2015, at 10:40 AM, John-Mark Gurney <jmg@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.
> 
> Why can't these algorithms use a cryptographically secure RNG instead?
> No one has truely answered that point..  Everyone says they want to use
> an insecure RNG, but the real question is, why can't/shouldn't these
> algorithms use a CSPRNG?
> 

Because of performance.  Not everything needs crypto-strength
randomness.

The problem here is that you are never going to accept the validity of
that statement no matter how many of us complain over and over again
about this kind of thing.  You've got some religion that the rest of us
don't buy into, and you've got it fervently enough that you'll just keep
saying the same mindless things over and over again until we all get
bored and wander away.

And freebsd gets a little more bloated and a little slower and a lot
less able to run on anything except the very fastest hardware that was
just released last week.  Thanks for "improving" it in that way.

-- Ian





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1424804722.3293.12.camel>