From owner-freebsd-arch@FreeBSD.ORG Tue Feb 24 18:25:11 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7316BEE9; Tue, 24 Feb 2015 18:25:11 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 36E8E176; Tue, 24 Feb 2015 18:25:11 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t1OIP7k3004633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Feb 2015 10:25:07 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t1OIP7NI004632; Tue, 24 Feb 2015 10:25:07 -0800 (PST) (envelope-from jmg) Date: Tue, 24 Feb 2015 10:25:07 -0800 From: John-Mark Gurney To: Alfred Perlstein Subject: Re: locks and kernel randomness... Message-ID: <20150224182507.GI46794@funkthat.com> References: <20150224012026.GY46794@funkthat.com> <20150224015721.GT74514@kib.kiev.ua> <54EBDC1C.3060007@astrodoggroup.com> <20150224024250.GV74514@kib.kiev.ua> <20150224174053.GG46794@funkthat.com> <54ECBD4B.6000007@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54ECBD4B.6000007@freebsd.org> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Tue, 24 Feb 2015 10:25:07 -0800 (PST) Cc: Konstantin Belousov , Harrison Grundy , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 18:25:11 -0000 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... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."