From owner-freebsd-arch@FreeBSD.ORG Tue Feb 24 18:53:17 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 443247A4 for ; Tue, 24 Feb 2015 18:53:17 +0000 (UTC) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.201.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E51726A3 for ; Tue, 24 Feb 2015 18:53:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id F0457E45F for ; Tue, 24 Feb 2015 13:53:14 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mailout.easymail.ca X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 required=5 tests=[ALL_TRUSTED=-1.8, AWL=-0.160, BAYES_00=-2.599, DNS_FROM_AHBL_RHSBL=0.692] Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alUhNW924xXF for ; Tue, 24 Feb 2015 13:53:14 -0500 (EST) Received: from bsddt1241.lv01.astrodoggroup.com (unknown [40.141.24.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 90F59E460 for ; Tue, 24 Feb 2015 13:53:14 -0500 (EST) Message-ID: <54ECC89B.9030805@astrodoggroup.com> Date: Tue, 24 Feb 2015 10:53:15 -0800 From: Harrison Grundy User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: locks and kernel randomness... 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> <20150224182507.GI46794@funkthat.com> In-Reply-To: <20150224182507.GI46794@funkthat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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:53:17 -0000 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