From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 08:50:34 2008 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 D3C021065670 for ; Wed, 17 Sep 2008 08:50:34 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 326E18FC0C for ; Wed, 17 Sep 2008 08:50:33 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.3/8.14.3) with ESMTP id m8H8oUdP058486 for ; Wed, 17 Sep 2008 12:50:30 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1221641431; bh=g1ojOPtLGPbvxYBJ97IjLyE5DyF8BGXb3ZXc5Ir QQQA=; l=2466; h=Date:From:To:Subject:Message-ID:References: MIME-Version:Content-Type:In-Reply-To; b=Ax5humpcyrFXefdp2/HdkmiQJ 9OzxN6pw0VYyZaceAL3VYPdh4uBWUOfyk3jFeQoZmOm90v7213nBNK1mAxsciRFhyz3 mzDBwFE6vv6OpEAKZWPwrL9KCRL5VJmNw9TsD694oVFR5anEBZsQkhMorku/Zj+22Im kkOi3yjK9sD8= Received: (from ache@localhost) by nagual.pp.ru (8.14.3/8.14.3/Submit) id m8H8oROe058483 for current@freebsd.org; Wed, 17 Sep 2008 12:50:27 +0400 (MSD) (envelope-from ache) Date: Wed, 17 Sep 2008 12:50:25 +0400 From: Andrey Chernov To: current@freebsd.org Message-ID: <20080917085024.GA57480@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , current@freebsd.org References: <20080916140319.GA34447@nagual.pp.ru> <20080916201932.GA59781@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080916201932.GA59781@zim.MIT.EDU> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: 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: Wed, 17 Sep 2008 08:50:34 -0000 On Tue, Sep 16, 2008 at 04:19:32PM -0400, David Schultz wrote: > Do you have a compelling example of why microoptimizing > arc4random() is an urgent matter? Most apps don't need > cryptographic-quality randomness thousands of times a second in > the critical path, and OpenBSD has been surviving just fine with > the calls to getpid(). arc4random() is just general PRNG. To confirm that OpenBSD itself treat arc4random() as general PRNG and use it _everywhere_ in their code instead of random() they phased out from every code piece. Contrary NetBSD don't have getpid() check at all like us now. Sooner or later some apps will want to use arc4random() intensively and having slowness here is not fundamental algo thing and can be avoided. > The patches I sent you essentially upgrade to the OpenBSD source > for arc4random() and try to minimize the diffs against them. (A > comparison of the resultant sources to OpenBSD's is below.) This > fixes several bugs, including: > > 1. silently using insecure entropy sources for jailed apps where > /dev/random is unavailable > 2. buffer sloppiness > 3. spurious restir checks > 4. the fork() problem you describe I agree with your patch (BTW you can remove unneded #define RANDOMDEV). I have exact the same plans to get rid of rs_stired and use rs_initialized only and use KERN_ARND as OpenBSD does, but can't consider or plan such big (but simple) changes in the paranoid atmosphere we already have around that unfortunate piece of code (and with review delays ~2months and increased) even with minimal step-by-step changes from our code towards OpenBSD one. Could you commit it, please? Hoping your commits will pass more easily than mine... > secteam@ already agreed to the idea of solving the fork problem as > in OpenBSD over a month ago. I really do not understand why we I don't hear about it. > need to keep trying to outdo OpenBSD with our own variant of > arc4random(). They addressed the fork() issue more than 5 years > ago and in general, they seem to be winning in terms of > correctness. > > 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 Speeding up getpid() by caching its value (as already discussed in this thread) looks like more general solution. -- http://ache.pp.ru/