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/Received on Tue Sep 16 2008 - 18:08:30 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:35 UTC