Re: 2.6.12-rc3 mmap lack of consistency among runs

[Arjan van de Ven <arjan@infradead.org>]

On Fri, 2005-04-29 at 12:44 +0000, Hubert Tonneau wrote:
> Andrew Morton wrote:
> >
> > Maybe you're being bitten by the address space randomisation.
> > 
> > Try
> > 	echo 0 > /proc/sys/kernel/randomize_va_space
> 
> Ok, it solves my issue, but:
> 
> . desabling it through 'echo 0 > /proc/sys/kernel/randomize_va_space' is not
>   a solution because only the application knows that it wants it to be desabled,
>   and the application is not root so cannot write to /proc; morever the
>   application can only speak for itself so desabling should be on a per process
>   bias.

there is the setarch command that you can use to disable it on a per
process basis.

> . second, my process restart succeeding roughly in 50% cases means that the
>   randomisation performed is just a toy. A virus assuming fixed memory layout
>   will still succeed 50% of times to install.

actually no. 
It just means that half the time the old value was below the current
boundary, and half the time above. Eg half the time it was in free
space.


> All in all, I'm not concerned about Linux kernel to randomise or not,
> but I need to have a reliable way to request a memory region and be granted
> that I can request the same one in a futur run.

glibc also has some randomisations in places (for cache performance) as
did kernels before 2.6.11 on p4 hyperthreading machines (granted that
was very small randomisation)

The only reliable ways I can think of is to either take a predetermined
address, or to mmap a big chunk first, then your real chunk and then
free the first chunk. Neither are clean or pretty