[RFC] malloc: add random offset to mmapped memory

[Rich Felker]

On Wed, Mar 04, 2015 at 03:39:05PM +0100, Maarten Bosmans wrote:
> 2015-03-02 18:40 GMT+01:00 Rich Felker <dalias@libc.org>:
> > On Sat, Jan 24, 2015 at 10:01:31PM +0100, Maarten Bosmans wrote:
> >> My proposal is to use the extra (unused) space that we get from mmap
> >> anyway (because it is page-aligned) to add an offset to the returned
> >> pointer. This would improve the performance of this example test case
> >> when the arrays are large enough to be mmapped directly.
> >>
> >> I would like to get some feedback whether glibc developers think this
> >> is a worthwhile goal to pursue, before I start working on a patch.
> >
> > I think you should be cautious not to introduce random perturbations
> > like this into programs where ASLR has been intentionally disabled. It
> > makes debugging certain types of issues extremely difficult.
> 
> What kind of problems do you see?
> 
> In my experience the pointer values that are returned from malloc are
> quite arbitrary already. Is this different with ASLR disabled?

In a non-multi-threaded program with ASLR disabled, results of malloc
are fully deterministic across multiple runs. This is important when
you're running a program in gdb, find an address where corrupting has
occurred, and want to re-run the program with watchpoints to catch the
corruption when it happens.

> I would not propose to get a 'real' random number (e.g. from rand() or
> /dev/urandom), but rather just something that is different from one
> malloc call to the next.
> For example something like
> void *malloc(size_t size) {
>     // ...
>     char *p; // let's say this pointer is set in the code above to the
> beginning of a mmapped segment
>     ptrdiff_t max_offset = ..;  // This is the unused space, the
> difference between requested size and the size of the mmapped segment
>     ptrdiff_t offset = (p ^ p>>32) % max_offset
>     return p + offset;
> }
> This basically makes sure if the original pointer was deterministic
> but page-aligned, the new code would return a pointer offset by some
> (non-fixed, but deterministic) offset.

I think this meets the conditions I was looking for with respect to
not interfering with debugging.

Rich