From owner-svn-src-all@freebsd.org Thu Jul 23 13:51:54 2015 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D9739A7EBB for ; Thu, 23 Jul 2015 13:51:54 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm26-vm1.bullet.mail.gq1.yahoo.com (nm26-vm1.bullet.mail.gq1.yahoo.com [98.136.216.128]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3D1B21EC8 for ; Thu, 23 Jul 2015 13:51:54 +0000 (UTC) (envelope-from scott4long@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1437659115; bh=OJI/NuHC6PPAE7x3/p9xfwtSON+2KahkYfNDgS/xv0M=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=AzhoahW8mN3pRtO5237k6wMjrZGKk+M22sCEhb0fo7JcHrZ/ty1bgaiWgAOB+tdWQsTJzuy6MYt/VdmjKAQK/NlHgDrwob+5+jcn1fxwqLat0UuzdbqL9YO8LTUXB0mLhKnkUzoU4Mcza5EfTdIA+g5J9n9bTox1FzGsamUg+Mdr6qz20mq9V1uhfrhWF+AJkMBJL6TZaQzf+Wnm5PpBI+XKnS9V/xq80tX5gx1+MXrsybF6ELZ0B2XUWRcTiRbg9IfXp+qTSQsnCvYeK8hsHjiE8xp8Bnpbze8IL2sPNkESkOm/3R6rr+gTss2d+LmVMPYhcMNNcJnX8O+wOvcGyg== Received: from [98.137.12.190] by nm26.bullet.mail.gq1.yahoo.com with NNFMP; 23 Jul 2015 13:45:15 -0000 Received: from [208.71.42.214] by tm11.bullet.mail.gq1.yahoo.com with NNFMP; 23 Jul 2015 13:45:15 -0000 Received: from [127.0.0.1] by smtp225.mail.gq1.yahoo.com with NNFMP; 23 Jul 2015 13:45:15 -0000 X-Yahoo-Newman-Id: 516106.92753.bm@smtp225.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: jS3AXXwVM1nW8NN.0U_0zheLyxxPzkF1nsiy0PfyzJgnexM Zg6x3IC7oYsjO7r.h.cZuYeNfoiSB45YZr3.p.W13c3z8Or9W2LHi_Cpwe6x kPFEdHo8JeEckUyFCQIaEWvVPdg16Ip5_m.OyOKxmYzHe_JuN0xWhK7aCwb6 xgR_R2Qf4P5X94UqJC5ZQb.XMBEVzH5tX8BWCnPRl_cj9TkCAw9OOCqfuqem F.xjiv81klUz4dstObk3QBn4M8pYnWwSNmg5RjzFtN3aVbIFlJ.EXCiXVWrH SFl6D_aR9Howmvopiip6YH4g.k_.pbcoi3aKRYTtl4h0A1bQihyTCtBqC94N NonrKi5DyOZm_gFoPoOUw5v6ChfURdNjtJvAMANxaFtYkwR1OpxcAPYeozkl vnf9iChui6K3tzkRGdL8ekiXfwPh9PzvKAbuRguqUYFQOG8H1L58JiTgYiJH Ya68FIyaL.UbwgifhZAvdTe5K.4iVM6PHH1cM0sc9t7EqPoFrrbaDQC8C2ZJ UkQIrUH7bMabNZNJBwQfH1I.8MP58fw-- X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random sy... From: Scott Long In-Reply-To: Date: Thu, 23 Jul 2015 07:45:14 -0600 Cc: Warner Losh , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <201506301700.t5UH0jPq001498@svn.freebsd.org> To: Mark R V Murray X-Mailer: Apple Mail (2.2098) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 13:51:54 -0000 > On Jul 23, 2015, at 1:03 AM, Mark R V Murray = wrote: >=20 >=20 >> On 23 Jul 2015, at 00:53, Warner Losh wrote: >>=20 >>>>> Neither filesystem operations nor allocations are random events. = They are trivially influenced by user code. A malicious attacker could = create repeated patterns of allocations or filesystem activity through = the syscall path to degrade your random sample source. >>>>=20 >>>> I?m not sure I accept that - Fortuna is very careful about using = non-reversible hashing in it?s accumulation, and countering such = degradation is one of the algorithm?s strong points. There is perhaps = risk of *no* entropy, but even the per-event timing jitter will be = providing this, if nothing else. >>=20 >> I=E2=80=99m not sure I=E2=80=99m happy about this answer. Do you have = some research backing up such cavalier claims? >=20 > It was not my intention to sound cavalier. Apologies. >=20 > Fortuna was developed to account for many sources of entropy, good and = bad alike, and Jeff=E2=80=99s observation is an attack on that design. I = accept that the randomness of these events is poor, but they are = high-rate, and this product of high-rate*low entropy is what I seek. I = pulled out numbers with dtrace, and basic statistics showed that the = harvesting was not useless. I completely understand that under the right = circumstances these numbers might be lousy - please read the Fortuna = design document to understand why this doesn=E2=80=99t matter. *ALL* = entropy inputs to Fortuna are considered attackable, including the = dedicated hardware sources. >=20 > I have also read cryptanalyses of Fortuna, not all of them to be sure, = and so far the design appears strong. The best attack that I have seen = (very academic) suggests an improvement which I may incorporate. >=20 >>>>> Perhaps more importantly to me, this is an unacceptable = performance burden for the allocator. At a minimum it should compile = out by default. Great care has been taken to reduce the fast path of the = allocator to the minimum number of cycles and even cache misses. >>>>=20 >>>> As currently set up in etc/rc.d/* by default, there is a simple = check at each UMA harvesting opportunity, and no further action. I asked = Robert Watson if this was burdensome, and he said it was not. >>>=20 >>> I find this burdensome. You can easily add a macro around the calls = or hide them in an inline with a default to off. Even a function call = that checks a global and does nothing else is a handful of new cache = misses. A microbenchmark will not realize the full cost of this. You = will instead get the dozen or so instructions of overhead which I still = find objectionable. >>>=20 >>> Kip's observations about packet cycle budgets in high-performance = applications are accurate and this is something we have put great care = into over time. >>=20 >> A certain video streaming company will be pushing the envelope to get = to 100Gbps very soon. Even a few extra instructions on every packet / = allocation will be a killer. Especially if one is an almost guaranteed = cache miss. This most certainly will be burdensome. There absolutely = must be a way to turn this off at compile time. We don=E2=80=99t care = that much about entropy to leave performance on the table. >=20 > OK - I=E2=80=99m sold! I=E2=80=99ll make a kernel option defaulting to = off. :-) >=20 >=20 Hi Mark, Thanks for making this concession. I wanted to add a bit of historical = perspective. When Yarrow was introduced in the previous decade, it was = initially wired into nearly all interrupt sources. It turned out to be = so expensive to those sources, especially for high-speed sources at the = time like network and caching RAID drivers, that we then spent months = disabling it from those sources. In the end, a lot of code thrash = happened and the effectiveness of Yarrow was questionable. Fast forward to now with your recent work. If UMA becomes expensive for = high-speed use, everyone will go back to developing private per-driver = and per-subsystem allocators to avoid it. This will happen whether or = not the UMA collector is controllable at run-time; if it=E2=80=99s = enabled by default, benchmarks will be impacted and people will react. = That=E2=80=99ll be a huge step backwards for FreeBSD. I also strongly agree with Jeff=E2=80=99s point on the questionable = nature of this kind of fast-and-monotonic entropy collection, and Warner = and Kip=E2=80=99s point on the finite number of clock cycles available = for doing 100Gb networking. If really high quality entropy is desired, = won=E2=80=99t most serious people use a hardware source instead of a = software source? Not that I think that software entropy is useless, but = it=E2=80=99s a question of how much effort and tradeoffs are put into it = for what result. An academically beautiful entropy system that = hamstrings the OS from doing other essential things isn=E2=80=99t all = that interesting, IMO. Scott