Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Feb 2015 13:04:59 -0500
From:      Alfred Perlstein <alfred@freebsd.org>
To:        John-Mark Gurney <jmg@funkthat.com>, Warner Losh <imp@bsdimp.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:  <54ECBD4B.6000007@freebsd.org>
In-Reply-To: <20150224174053.GG46794@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>

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


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.

So we should get rid of rand(3)?  When do we deprecate that?

Your argument doesn't hold water.

-Alfred



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