From owner-freebsd-arch@FreeBSD.ORG Wed Feb 25 01:01:15 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 324EAB6F for ; Wed, 25 Feb 2015 01:01:15 +0000 (UTC) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) (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 F064E7C8 for ; Wed, 25 Feb 2015 01:01:14 +0000 (UTC) Received: by padet14 with SMTP id et14so827562pad.11 for ; Tue, 24 Feb 2015 17:01:08 -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=H2UwMSj67y6qzU4Dyor85OSkqQEgxvfCQQqI2An5tYo=; b=W6VeGINnAQIx3V7gqoIT4+60Z6D0F+ho0fnHMs3PMlJRI837hBigJq+rJauVioXbu8 uWaa+K3SwCrhjYh64tH//n2+Ah3tYHk1Bbt3plyc98x2pQOWBMmrJyRp+VD0nNyaOsV6 +8+rLCACC/EwqgaVV8v3tLHo3L4RTNe1eEij7o8wLv4tzL1wbeOjF+I9OITo6/OgxG4S b5ki+xfk7FY9x2oBahSoSycmAdD3YS9l0pIrU9LbbcFFT6+uM4ye0xZvKRNR+3RYjIBx BSD0bdUhe7uGeIrOO/nb4kEdwuMHpHWw9kda+3KLUV/QcALDLAOBmccDm9zTFF0bJM1w Wjsw== X-Gm-Message-State: ALoCoQmL97YvQnRv29QBGyp4IpgGvYY+6M494zYgSzoBZSKw20CI10L/TQoAm1LPCpaO2U14g0UM X-Received: by 10.68.201.168 with SMTP id kb8mr790054pbc.89.1424826068168; Tue, 24 Feb 2015 17:01:08 -0800 (PST) Received: from macintosh-3c0754232d17.corp.netflix.com ([69.53.236.236]) by mx.google.com with ESMTPSA id cf12sm15082219pdb.43.2015.02.24.17.01.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Feb 2015 17:01:06 -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: <20150225002956.GT46794@funkthat.com> Date: Tue, 24 Feb 2015 18:01:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2F49527F-2F58-4BD2-B8BE-1B1190CCD4D0@bsdimp.com> References: <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> <54ECEA43.2080008@freebsd.org> <20150224231921.GQ46794@funkthat.com> <1424822522.1328.11.camel@freebsd.org> <20150225002956.GT46794@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.2070.6) Cc: Konstantin Belousov , Harrison Grundy , Alfred Perlstein , Ian Lepore , 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: Wed, 25 Feb 2015 01:01:15 -0000 > On Feb 24, 2015, at 5:29 PM, John-Mark Gurney = wrote: >=20 > Ian Lepore wrote this message on Tue, Feb 24, 2015 at 17:02 -0700: >> On Tue, 2015-02-24 at 15:19 -0800, John-Mark Gurney wrote: >>> Alfred Perlstein wrote this message on Tue, Feb 24, 2015 at 16:16 = -0500: >>>> On 2/24/15 1:25 PM, 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. >>>>>>>=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 >>>>>> The way I read this argument is that no low quality sources of >>>>>> randomness shall be allowed. >>>>>=20 >>>>> 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.. >>>>>=20 >>>>>> So we should get rid of rand(3)? When do we deprecate that? >>>>>=20 >>>>> 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.. >>>>>=20 >>>>>> Your argument doesn't hold water. >>>>>=20 >>>>> 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? >>>>>=20 >>>>> 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... >>>>=20 >>>> That speaks to more of the drive-by czars we have in BSD land that = take=20 >>>> an area with a hard lock and then go away. >>>=20 >>> It also speaks to the airchair quarterbacking that stops people from >>> wanting to contribute... Someone comes along and tries to make an >>> improvement, then x number of people raise their arms about oh, I >>> still use grdc (sorry dteske, not trying to pick on you) as tcp keep >>> alive, and then the person abandons or leaves incomplete the work = that >>> they started... >>>=20 >>> I was very close to NOT posting the email to -arch, but after = various >>> questions from twitter, and adrian's continued pleas to talk changes >>> more publicly, I decided to do so... If people continue to react = this >>> way, it just demonstrates that doing things publicly is NOT a way to >>> get things to move forward in FreeBSD, and people will continue to = do >>> things in private... Luckily, I'm consulting, so I have a few more >>> hours (for now) to fight these fights, but if it continues to be an >>> issue, we'll continue to have this problem of czars that come in, = drop >>> a bunch of code and then leave, because dealing w/ this becomes too >>> expensive... >>>=20 >>> So far, only ONE person has commented on the patch on reviews, and = that >>> is delphij... >>>=20 >>>> Also, do not want to attempt to be like openbsd, learn from for = sure,=20 >>>> but to be like, no way. >>>=20 >>> I'm fine not being like OpenBSD, but as you said, we should learn = from >>> them, and leverage their work... Though I agree w/ OpenBSD's work = to >>> replace random(3), it also isn't who FreeBSD is, but if we want to >>> continue to be relevant, we do need to take security seriously, and >>> IMO, this is one of those steps. >>>=20 >>> If someone does find a performance issue w/ my patch, I WILL work = with >>> them on a solution, but I will not work w/ people who make unfounded >>> claims about the impact of this work... >>=20 >> Yeah, the problem could all that. >>=20 >> Or it could be people who "collaborate" by saying I'm going to make = this >> change. I'm not going to justify it in any way, and if anybody >=20 > I have justified it=E2=80=A6 I think you should explain what you explained to me on IRC. Specifically, through a timing attack, you can find (by default) the = lower 7 bits of the value returned by random(). Since random() is not MP safe, it can sometimes return the same value twice (through some race that may or may not have been lost). This means other users can see this data. In this instance, it isn=E2=80=99t so much what sched_ule is doing, but = rather what others are able to glean from it. Now, it isn=E2=80=99t clear that these = 7 bits are a big deal since you also have to lose the race and know the race was lost. = Other things in the system might care if you expose this state. Also, in this specific case, it can use the current random generator in = sched_ule to get this number as well. It=E2=80=99s run on a time scale of ticks, = with some jitter. In this specific case, it doesn=E2=80=99t need to be using random(), but = it isn=E2=80=99t clear if the get_cyclecount() stuff provides enough low-order bits that are = random enough to meet sched_ule=E2=80=99s needs. But it isn=E2=80=99t clear = that it doesn=E2=80=99t (only cause for concern is if there=E2=80=99s a beat pattern for a cycle count = that=E2=80=99s low-resolution, but I don=E2=80=99t think we have any of these on SMP work loads). Ideally, since there=E2=80=99s a small chance of a performance = regression, we should find some benchmark to run that would exercise this code path and see if a regression can be measured or not. After looking at the code, I=E2=80=99= m skeptical that there would be one. But data would settle this once and for all, = since this is an interaction with the scheduler, which historically has made people = very nervous.=20 >> disagrees I'm just going to dismiss their concerns and demand that = THEY >> hold the burden of proof that my unnecessary change is harmful, and = if >=20 > How many audits of the random() calls in the kernel have you done? >=20 > You've raised concers, I've said I've looked and don't see any, how = can > I prove a negative? What can I do to convince you that you're wrong? > All you have to do to convince me I'm wrong is show me a place in the > kernel where it is a performance issue. Is it really that hard to > come up w/ one? You can prove a negative with benchmarks. Then we=E2=80=99d be arguing = over the efficacy of them, but at least that would be progress :) Or you can = strongly suggest a negative by failing to reject the null hypothesis of no = change. That too would be progress. >> they don't, then screw the collobaration thing, I'm just going to do = it >> anyway. >=20 > It goes both ways, I see it that you're objecting w/o complete > intformation, and no mater what evidence or work I do, you'll just > ignore it, and still say it isn't correct or that there's this > unprovable codition that prevents the work for going in=E2=80=A6 Data is going to break this log-jam. Warner