From owner-svn-src-head@freebsd.org Wed Jul 22 22:55:20 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 B7C259A8E37 for ; Wed, 22 Jul 2015 22:55:20 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) (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 8E6071CF3 for ; Wed, 22 Jul 2015 22:55:20 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by pdrg1 with SMTP id g1so145666443pdr.2 for ; Wed, 22 Jul 2015 15:55:14 -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=ocaaglV+Xc6WmwwjHeATgSoI/PgaPT+0pf/2qxftXOQ=; b=N3db+N3S87VDzax/EV3uzhnGhCtfkEPytGuPDkAT0FI6Op9DkLX9Xja7hfkvhfTWAZ CHbzjWxmQPy4BydYWsAHOQGZgb8juIlW1tceBnjLoY8NqLjDa6pcZVh5nfzj9S2TVyO5 DfWY/HKD23rxQQgW1dNrvZMTsGGsu9v9M2SZ2YCEfKxGd9Ab8xYMav4WuHqRPObRJBmi cZja6qSCHsmvohSGXikrvFLLMxLwFqxVoZEq47rpjGGnbLHndEEkky754Xy/tK0VzcPE pSPrYq4r6BpbnnsUg/mhjstQHtkEKDEAdrECspRLadklLKAJBi2SgvL0idi5hMRR6RCm XKMw== X-Gm-Message-State: ALoCoQn0NkOGEWajNonoP+oieZ+ZbsDIpUDJYG79trggxsuRmj2Gwn5I6bxkK1FqdZBCVt3mav2P X-Received: by 10.70.38.10 with SMTP id c10mr11041193pdk.72.1437605714376; Wed, 22 Jul 2015 15:55:14 -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 i10sm5154257pdr.78.2015.07.22.15.55.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jul 2015 15:55:13 -0700 (PDT) Date: Wed, 22 Jul 2015 12:53:21 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Mark R V Murray cc: src-committers@freebsd.org, 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-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: Wed, 22 Jul 2015 22:55:20 -0000 On Wed, 22 Jul 2015, Mark R V Murray wrote: > >> On 22 Jul 2015, at 22:42, Jeff Roberson wrote: >> >> On Tue, 30 Jun 2015, Mark Murray wrote: >> >>> - Add harvesting of slab allocator events. This needs to be checked for >>> weighing down the allocator code. >> >> 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. > >> 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. Thanks, Jeff > > I?m willing to discuss optimising this, and have plans for some > micro-benchmarks. > > M > -- > Mark R V Murray > > PS: Please trim mail when responding - was it necessary to send me back the whole commit message and diff? >