Is fork() hook ever possible?

Andrey Chernov ache at
Sat Nov 12 17:15:34 UTC 2011

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 
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 
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).


More information about the freebsd-current mailing list