From owner-freebsd-arch@FreeBSD.ORG Tue Feb 24 20:06:48 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 0F044FDB for ; Tue, 24 Feb 2015 20:06:48 +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 D1F41EF3 for ; Tue, 24 Feb 2015 20:06:47 +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 t1OK6isl005322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Feb 2015 12:06:44 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t1OK6hrZ005321; Tue, 24 Feb 2015 12:06:43 -0800 (PST) (envelope-from jmg) Date: Tue, 24 Feb 2015 12:06:43 -0800 From: John-Mark Gurney To: Warner Losh Subject: Re: locks and kernel randomness... Message-ID: <20150224200643.GN46794@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> <1E4A5E62-6E06-48BA-B5C5-9BD05811CDEF@bsdimp.com> <20150224183051.GJ46794@funkthat.com> <8157A5FC-C402-4C77-8535-AAF73BB64E8E@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8157A5FC-C402-4C77-8535-AAF73BB64E8E@bsdimp.com> 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 12:06:44 -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 20:06:48 -0000 Warner Losh wrote this message on Tue, Feb 24, 2015 at 12:45 -0700: > > > On Feb 24, 2015, at 11:30 AM, John-Mark Gurney wrote: > > > > Warner Losh wrote this message on Tue, Feb 24, 2015 at 11:03 -0700: > >> > >>> On Feb 24, 2015, at 10:40 AM, 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.. > >> > >> Why don???t you support having a common random routine that???s to mix the > >> pot, but not cryptographically secure? Lots of algorithms use them, and having > >> a common one would keep us from reinventing the wheel. > > > > Why can't these algorithms use a cryptographically secure RNG instead? > > No one has truely answered that point.. Everyone says they want to use > > an insecure RNG, but the real question is, why can't/shouldn't these > > algorithms use a CSPRNG? > > They could, assuming that no locks are needed to get this and the computation > isn???t too large because this is in the fast path of the kernel. They just don???t need > it to be that strong. Not having any other interactions with the rest of the system > is also desirable. I agree about having no interations w/ other parts of the system, which is why I posted the original email.. Asking for help/advice w/ the problem... Instead of help, all I've received is but you'll make my system slow, because and other less helpful comments... > Historically, a CSPRNG is spelled rand() or random(). So by calling those functions, > they are saying they want that. Some callers need more, others do not. Citation please? In my copy of the C99 specification, the rand function says nothing about being cryptographicly secure.. and the srand function specificly states that after calling srand, rand will be seeded w/ a unsigned int, or 32bits, so by definition not CSPRNG.. Also, Single UNIX Specification: http://pubs.opengroup.org/onlinepubs/007908799/xsh/rand.html has the same definition. As for random() from our own man page: The random() function uses a non-linear additive feedback random number generator employing a default table of size 31 long integers to return successive pseudo-random numbers in the range from 0 to (2**31)-1. The oh, and immediately before that, it says: The functions described in this manual page are not cryptographically secure. Cryptographic applications should use arc4random(3) instead. So, I really would like to know where you get the idea the rand() and random() are CSPRNG.. Though I'm fine w/ making them so.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."