From owner-freebsd-arch@FreeBSD.ORG Tue Feb 24 19:45:46 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 9F67E930 for ; Tue, 24 Feb 2015 19:45:46 +0000 (UTC) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D343CDB for ; Tue, 24 Feb 2015 19:45:46 +0000 (UTC) Received: by pabkq14 with SMTP id kq14so38455683pab.3 for ; Tue, 24 Feb 2015 11:45:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=NTu2Y9PGr/c4fbh+NdT3+JK330H/BB0dYSJAOvzYo0U=; b=WdERFpPQmPf7VetrnxXJ9y0N2xk/bcRr9vp93D9yank7xSYI6yn4XWxR+FozjT/Z49 I+I50YlJLE6i6YWmIkRgAkC8GTp8rzdlcEQH7+VhagVweD4L5p0c7CtmOEmnsFfK8olV kNFD74mVOCKeZVOlU32cQuPnSen3aD7jVozCF8fTuuH1hd7Ze43QK1+ZDJLrGjMMkBOV jeQFpM5XrFTUNxfCAR6FsCxxVyZ3V6043/nEwX0KqaDb+BUaZ29qYJExcrQCEqch03Af p4dCuXYGLVs6hCbbwvF3nVJnNK7xkkdIVff8GlZlzjDj7Mo8gw0bWCGjfpg6xTdJaZYU ItbQ== X-Gm-Message-State: ALoCoQnEkdJd49qOeOxKI8kjyFkohKMdmwaetJD9F6OE/R/6TJW55lZeCyG6+MigTfgzZV5/DVpq X-Received: by 10.70.140.130 with SMTP id rg2mr1998365pdb.49.1424807145367; Tue, 24 Feb 2015 11:45:45 -0800 (PST) Received: from macintosh-3c0754232d17.corp.netflix.com ([69.53.236.236]) by mx.google.com with ESMTPSA id pa6sm30056613pac.45.2015.02.24.11.45.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Feb 2015 11:45:44 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: locks and kernel randomness... From: Warner Losh In-Reply-To: <20150224183051.GJ46794@funkthat.com> Date: Tue, 24 Feb 2015 12:45:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8157A5FC-C402-4C77-8535-AAF73BB64E8E@bsdimp.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> To: John-Mark Gurney X-Mailer: Apple Mail (2.2070.6) 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 19:45:46 -0000 > On Feb 24, 2015, at 11:30 AM, John-Mark Gurney = wrote: >=20 > Warner Losh wrote this message on Tue, Feb 24, 2015 at 11:03 -0700: >>=20 >>> On Feb 24, 2015, at 10:40 AM, John-Mark Gurney = wrote: >>>=20 >>> 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. >>>=20 >>> 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... >>>=20 >>> It appears that the scheduler had an LCG but for some reason the = authors >>> didn't feel like using it here.. >>=20 >> 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. >=20 > 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=E2=80=99t too large because this is in the fast path of the kernel. = They just don=E2=80=99t need it to be that strong. Not having any other interactions with the rest of = the system is also desirable. 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. Warner=