From owner-freebsd-arch@FreeBSD.ORG Tue Feb 24 18:01:30 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D97C5D0 for ; Tue, 24 Feb 2015 18:01:30 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id EB45CE8B for ; Tue, 24 Feb 2015 18:01:29 +0000 (UTC) Received: from AlfredMacbookAir.local (unknown [12.133.26.10]) by elvis.mu.org (Postfix) with ESMTPSA id DE9D4341F910; Tue, 24 Feb 2015 10:01:28 -0800 (PST) Message-ID: <54ECBD4B.6000007@freebsd.org> Date: Tue, 24 Feb 2015 13:04:59 -0500 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: John-Mark Gurney , Warner Losh 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> In-Reply-To: <20150224174053.GG46794@funkthat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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:01:30 -0000 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