From owner-svn-src-all@freebsd.org Thu Jul 23 08:01:38 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 2E7639A7BCD for ; Thu, 23 Jul 2015 08:01:38 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) (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 D0B371FFF for ; Thu, 23 Jul 2015 08:01:36 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by pachj5 with SMTP id hj5so153396378pac.3 for ; Thu, 23 Jul 2015 01:01:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type; bh=ybk7SHl/xqETe0rp8B7UbhazlXPo2IjWWSzoU2ZPW0o=; b=O6mIesfjyUiUzyShiZ9RGlJtzEPVPnkxXw9eGnvL6nn5uwRbyDjhJbe5lTE4tpOnRJ duwn+vmyPNr4spodM4B51/+vRq5ILq9hyqmHmuF/pt9L0iJ+J4n/PVkCNFTbKU4/43iJ vkxKcJy1DxUuKg8gT0lt/gHwJJeSQfnIdmj8R6SNGNq52qKcqPFXamyYs+JWbhQSu6vI tKGGnCHGzMaC2jnF7MT2aQNTXF1nH60evPj42CxZhEGPOsLEW4suF7lE3iS7DeinmAXd oMqxGprvsdGcTjS4G3MYmAFEqSTldQJL1qj0OESL84IdyAcfxDnoL7XmmWt1MapZfTKD fSzQ== X-Gm-Message-State: ALoCoQkQbNixKyp/on3pEzd8YBjDeVdaQagSA/awSfaJ9QTlqMmoiEtUvSNsFv/t232pviYjREkj X-Received: by 10.66.132.16 with SMTP id oq16mr15946422pab.13.1437638494205; Thu, 23 Jul 2015 01:01:34 -0700 (PDT) Received: from rrcs-66-91-135-210.west.biz.rr.com (rrcs-66-91-135-210.west.biz.rr.com. [66.91.135.210]) by smtp.gmail.com with ESMTPSA id j9sm1816220pdl.65.2015.07.23.01.01.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jul 2015 01:01:33 -0700 (PDT) Date: Wed, 22 Jul 2015 21:59:39 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Mark R V Murray cc: Warner Losh , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org 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... In-Reply-To: Message-ID: References: <201506301700.t5UH0jPq001498@svn.freebsd.org> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed 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 08:01:38 -0000 On Thu, 23 Jul 2015, Mark R V Murray wrote: > >> On 23 Jul 2015, at 00:53, Warner Losh wrote: >> >>>>> 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. >>>> >>>> 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. >> >> I?m not sure I?m 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?s 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?t 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. >>>> >>>> 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. >>> >>> 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. >>> >>> 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. >> >> 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?t care that much about entropy to leave performance on the table. > > OK - I?m sold! I?ll make a kernel option defaulting to off. :-) There are other sources that occur less frequently than millions of times per-second that may still provide some usefull entropy while being less performance critical under normal conditions. For example, context switches, traps, etc. I could also imagine wiring up a pmc counter to something like cache misses or branch mispredicts that would be more difficult to game, especially if the counter was cycled irregularly. Thanks, Jeff > > M > -- > Mark R V Murray > >