Date: Wed, 17 Sep 2008 00:08:23 +0400 From: Andrey Chernov <ache@nagual.pp.ru> To: Max Laier <max@love2party.net> Cc: Daniel Eischen <deischen@freebsd.org>, freebsd-current@freebsd.org Subject: Re: Is fork() hook ever possible? Message-ID: <20080916200822.GA44273@nagual.pp.ru> In-Reply-To: <200809162148.24090.max@love2party.net> References: <20080916140319.GA34447@nagual.pp.ru> <200809161827.07627.max@love2party.net> <20080916164558.GA41258@nagual.pp.ru> <200809162148.24090.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 16, 2008 at 09:48:23PM +0200, Max Laier wrote: > Slow down here. You haven't answered my question. What exactly is the issue > this is supposed to fix? Do we want to prevent a child from knowing what the > next few arc4random outputs of its parent will be? Or are we only concerned > that the next few arc4random of the parent and child should not be the same? The child and the parent should have different arc4random() states to produce different returns, say, for mktemp() they both called after fork() (or for any other function inside libs which use arc4random()). To achieve that it is enough to re-stir in the child only. > > Could you add a new interface, arc4random_setstir() or something, > > to set a flag that indicates a stir should be done at the next > > opportunity? > > ... this certainly is the right solution. arc4random() should not care about > pids and such - IMHO, of course. Perhaps clearing rs_stired flag just for arc4random() instead of general getpid() speedup will be the right solution, because we have an edge case: vfork() for which there is no sense to re-stir at all because both the parent and the child will be re-stired at the same time in any case. -- http://ache.pp.ru/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080916200822.GA44273>