Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Feb 2015 10:53:15 -0800
From:      Harrison Grundy <harrison.grundy@astrodoggroup.com>
To:        freebsd-arch@freebsd.org
Subject:   Re: locks and kernel randomness...
Message-ID:  <54ECC89B.9030805@astrodoggroup.com>
In-Reply-To: <20150224182507.GI46794@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> <54ECBD4B.6000007@freebsd.org> <20150224182507.GI46794@funkthat.com>

next in thread | previous in thread | raw e-mail | index | archive | help


On 02/24/15 10:25, John-Mark Gurney wrote:
> Alfred Perlstein wrote this message on Tue, Feb 24, 2015 at 13:04
> -0500:
>> On 2/24/15 12:40 PM, John-Mark Gurney 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..
>> 
>> The way I read this argument is that no low quality sources of 
>> randomness shall be allowed.
> 
> No, I'm saying that the person who needs the predictable
> randomness needs to do extra work to get it...  If they care that
> much about performance/predictability/etc, then a little extra work
> won't hurt them..  And if they don't know what an LCG is, then they
> aren't qualified to make the decision that a weaker RNG is correct
> for their situation..
> 
>> So we should get rid of rand(3)?  When do we deprecate that?
> 
> No, we should replace it w/ proper randomness like OpenBSD has... 
> I'm willing to go that far and I think FreeBSD should...  OpenBSD
> has done a lot of leg work in tracking down ports that correctly
> use rand(3), and letting them keep their deterministic randomness,
> while the remaining get real random..
> 
>> Your argument doesn't hold water.
> 
> Sorry, you're argument sounds like it's from the 90's when we
> didn't know any better on how to make secure systems...  Will you
> promise to audit all new uses of randomness in the system to make
> sure that they are using the correct, secure API?
> 
> Considering that it's been recommended that people NOT use 
> read_random(9) for 14 years, yet people continue to use it in new
> code, demonstrates that people do not know what they are doing
> (wrt randomness), and the only way to make sure they do the
> correct, secure thing is to only provide the secure API...
> 

I think a large part of this issue is, in the end, terminology.

Developers call "random()" when they actually mean a whole lot of
different things, from ULE's "I need a number here that changes some
so this value jitters" to "I'm trying to create an OTP to protect this
letter from the NSA and don't have time to break out my geiger counter."

A single function simply won't meet all of these needs. I believe the
default behavior *should* be a CSPRNG, simply so that if someone
hasn't fully considered what they need, their code will still be
"safe" (as far as random numbers go, anyway). That being said, if
someone *has* considered the problem, there is no particular reason to
force them to write yet another implementation of something thousands
of other people have written.

I propose converting random() to be a true, SMP-safe, CSPRNG so that
the default behavior is as secure as possible, and the creation of
"fauxrandom()" (Or some such thing... hopefully someone has a better
name) for those circumstances where one can accept the degradation in
random number randomness, in exchange for a significant performance
improvement. By having both options available, and documenting the
difference between them, we can generally get the best of both worlds.

I don't believe there is a programming solution to solving the problem
of a developer who is wrong also being sure about what sort of
"random" they need.

--- Harrison



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