From owner-svn-src-head@freebsd.org Thu Jul 23 07:03:59 2015 Return-Path: Delivered-To: svn-src-head@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 A5FA49A6D65; Thu, 23 Jul 2015 07:03:59 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 62CB61505; Thu, 23 Jul 2015 07:03:59 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85 (FreeBSD)) (envelope-from ) id 1ZIAXr-000LWe-JR; Thu, 23 Jul 2015 08:03:56 +0100 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... Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: text/plain; charset=utf-8 From: Mark R V Murray In-Reply-To: Date: Thu, 23 Jul 2015 08:03:49 +0100 Cc: 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: Warner Losh X-Mailer: Apple Mail (2.2102) X-SA-Score: -1.0 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 07:03:59 -0000 > 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? It was not my intention to sound cavalier. Apologies. 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. 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. >>>> 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. OK - I=E2=80=99m sold! I=E2=80=99ll make a kernel option defaulting to = off. :-) M --=20 Mark R V Murray