Is fork() hook ever possible?
Andrey Chernov
ache at freebsd.org
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
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/
More information about the freebsd-current
mailing list