From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 17:15:33 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6113106566C; Sat, 12 Nov 2011 17:15:33 +0000 (UTC) (envelope-from ache@vniz.net) Received: from vniz.net (vniz.net [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 4F5228FC13; Sat, 12 Nov 2011 17:15:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vniz.net (8.14.5/8.14.5) with ESMTP id pACHFVXA083776; Sat, 12 Nov 2011 21:15:31 +0400 (MSK) (envelope-from ache@vniz.net) Received: (from ache@localhost) by localhost (8.14.5/8.14.5/Submit) id pACHFVax083775; Sat, 12 Nov 2011 21:15:31 +0400 (MSK) (envelope-from ache) Date: Sat, 12 Nov 2011 21:15:31 +0400 From: Andrey Chernov To: current@freebsd.org, secteam@freebsd.org Message-ID: <20111112171531.GA83419@vniz.net> Mail-Followup-To: Andrey Chernov , current@freebsd.org, secteam@freebsd.org, das@freebsd.org References: <20080916140319.GA34447@nagual.pp.ru> <20080916201932.GA59781@zim.MIT.EDU> <20111112102241.GA75396@vniz.net> <20111112154135.GA21512@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111112154135.GA21512@zim.MIT.EDU> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: das@freebsd.org Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 17:15:34 -0000 On Sat, Nov 12, 2011 at 10:41:35AM -0500, David Schultz wrote: > On Sat, Nov 12, 2011, Andrey Chernov wrote: > > On Tue, Sep 16, 2008 at 04:19:32PM -0400, David Schultz wrote: > > > secteam@ already agreed to the idea of solving the fork problem as > > > in OpenBSD over a month ago. > > > > On Wed, Sep 17, 2008 at 12:50:25PM +0400, Andrey Chernov wrote: > > > I agree with your patch (BTW you can remove unneded #define RANDOMDEV). > > > > The question remains: why you don't commit this patch all that 3 > > years, having secteam@ and mine agreements too? > > Sorry, but in the three years that have intervened, my brain has > paged out the relevant context. As I recall, there were issues > with some of your changes to arc4random() and I proposed tracking > OpenBSD's implementation more closely. I can't say for secteam@ side (it was you who said that they agree), but personally me still agree with your proposal and still see security problem in our current implementation, like the same-generated tmp names after fork in son and parent. > If everyone's in agreement on that, please go ahead and commit the changes. I can't... It seems I reach dead end talking to our @secteam. In few words, they: 1) Explicitly disallow my commits in all 'random' areas until their review. 2) They never do that review (I must to mention again that 3 years passed since they promise it). Being particular, I suggest them to use your patch at the end. Nothing happens. Hope you'll get more luck with them committing it by yourself. > On a related note, I recall that the biggest issue is that > getpid() overhead now dominates the cost of arc4random(). > The title of this thread suggests a simple solution! I initially thinking about making fork hook which will change arc4random reinit variable. You express just opposite opinion those times: On Tue, Sep 16, 2008 at 04:19:32PM -0400, David Schultz wrote: > If getpid() really winds up being a serious problem, we can solve > it in a principled way, e.g., by having the kernel fault in a > read-only page containing the current process pid, and having > libc's getpid() read it. I know Windows has a facility like this > that they use for a number of things, and ISTR that Linux recently > introduced one, too. The bottom line is that we shouldn't solve > the problem with hacks in arc4random(), and we shouldn't try to > solve it at all until it's proven to be a real problem. I run some tests but can't come to conclusion, is overhead is significant or not for real life tasks (which usually don't call arc4random() very often in the loop). -- http://ache.vniz.net/