Re: Is fork() hook ever possible?

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_at_ 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/