On Wed, Dec 02, 2009 at 02:44:21PM +0100, Otto Moerbeek wrote:
> On Wed, Dec 02, 2009 at 02:25:57PM +0100, Otto Moerbeek wrote:
>
> > On Wed, Dec 02, 2009 at 01:09:02PM +0000, Michael Shalayeff wrote:
> >
> > > On Wed, Dec 02, 2009 at 10:38:10AM +0100, Otto Moerbeek wrote:
> > > > Hi,
> > > re
> > >
> > > > apart from the random page addresses obtained form mmap(2) malloc(3)
> > > > itself also randomizes cache en chunk operations. It uses a nibble of
> > > > randomness per call, so optimize that to not waste half the random
> > > > bits.
> > >
> > > arc4 random does not use entropy and is very cheap
> > > almost the speed of memory copy. "caching" arc4 output
> > > like this is the same as running rot13 twice (:
> >
> > at least it saves on calls to arc4_stir() and thus on sysctl(2) and
> > getpid(2) calls.
>
> I was a bit puzzled by mickeys comment, remenbering that the kernel
> arc4 does use entropy, and indeed rc4random_buf() in the kernel which
> provides the random data for stirring the userland arc4random(3) calls
> arc4maybeinit() which potentially consumes entropy via arc4_stir() and
> get_random_bytes(). The the trigger to stir in the kernel is timer
> based, not consumption based.
amount of data required to reinitialise the arc4 pool is
almost nothing compared to amounts of data produced.
the pool is 256 bytes and we produce 1.6MEGAbytes from it.
what program would call malloc more than 1.6 million times?
perhaps if it does it shall be fixed (:
of course savings on getpid() might be worth fighting for.
cu
--
paranoic mickey (my employers have changed but, the name has remained)
