This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] malloc: add random offset to mmapped memory
- From: Rich Felker <dalias at libc dot org>
- To: Maarten Bosmans <mkbosmans at gmail dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 4 Mar 2015 11:09:27 -0500
- Subject: Re: [RFC] malloc: add random offset to mmapped memory
- Authentication-results: sourceware.org; auth=none
- References: <CA+CvcKSNz=kWgeQL_Y9RoAtk5Bn1xOocymwCg7QcJ7rC_dDn+A at mail dot gmail dot com> <20150302174026 dot GX23507 at brightrain dot aerifal dot cx> <CA+CvcKT1T=D6WAxDYfzA=8qgw3v7j39GDG2rR2EvYQhDcJDaRA at mail dot gmail dot com>
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