Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Feb 2015 17:02:02 -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>, Alfred Perlstein <alfred@freebsd.org>, freebsd-arch@freebsd.org
Subject:   Re: locks and kernel randomness...
Message-ID:  <1424822522.1328.11.camel@freebsd.org>
In-Reply-To: <20150224231921.GQ46794@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> <54ECEA43.2080008@freebsd.org> <20150224231921.GQ46794@funkthat.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2015-02-24 at 15:19 -0800, John-Mark Gurney wrote:
> Alfred Perlstein wrote this message on Tue, Feb 24, 2015 at 16:16 -0500:
> > On 2/24/15 1:25 PM, 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...
> > 
> > That speaks to more of the drive-by czars we have in BSD land that take 
> > an area with a hard lock and then go away.
> 
> It also speaks to the airchair quarterbacking that stops people from
> wanting to contribute...  Someone comes along and tries to make an
> improvement, then x number of people raise their arms about oh, I
> still use grdc (sorry dteske, not trying to pick on you) as tcp keep
> alive, and then the person abandons or leaves incomplete the work that
> they started...
> 
> I was very close to NOT posting the email to -arch, but after various
> questions from twitter, and adrian's continued pleas to talk changes
> more publicly, I decided to do so...  If people continue to react this
> way, it just demonstrates that doing things publicly is NOT a way to
> get things to move forward in FreeBSD, and people will continue to do
> things in private...  Luckily, I'm consulting, so I have a few more
> hours (for now) to fight these fights, but if it continues to be an
> issue, we'll continue to have this problem of czars that come in, drop
> a bunch of code and then leave, because dealing w/ this becomes too
> expensive...
> 
> So far, only ONE person has commented on the patch on reviews, and that
> is delphij...
> 
> > Also, do not want to attempt to be like openbsd, learn from for sure, 
> > but to be like, no way.
> 
> I'm fine not being like OpenBSD, but as you said, we should learn from
> them, and leverage their work...  Though I agree w/ OpenBSD's work to
> replace random(3), it also isn't who FreeBSD is, but if we want to
> continue to be relevant, we do need to take security seriously, and
> IMO, this is one of those steps.
> 
> If someone does find a performance issue w/ my patch, I WILL work with
> them on a solution, but I will not work w/ people who make unfounded
> claims about the impact of this work...
> 

Yeah, the problem could all that.

Or it could be people who "collaborate" by saying I'm going to make this
change.  I'm not going to justify it in any way, and if anybody
disagrees I'm just going to dismiss their concerns and demand that THEY
hold the burden of proof that my unnecessary change is harmful, and if
they don't, then screw the collobaration thing, I'm just going to do it
anyway.

-- Ian





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