jemalloc malloc_usable_size()

From: Andrea Campi <andrea+freebsd_current_at_webcom.it>
Date: Sun, 23 Sep 2007 11:18:08 +0000
Hi all,

for a university project, I have been working on a LD_PRELOAD wrapper
for the string.h functions, similar in concept to HeapShield [1]. In
short, I wrap all functions, determine the size of the usable
allocation, then (if available) I translate the original call into a
safer one (strcpy becomes strlcpy, and so on).

I have been mostly targeting 6.x, where I wrote my own code to figure
out the allocation size. On 7.x though, I figured I could use
malloc_usable_size(). However, I encountered a few problems.

First of all, jemalloc makes no effort (neither here nor in free(3))
to survive being called with non-malloc'ed pointers. If you do that
and asserts are on, you will get an abort, but if they are not your
process will likely die an horrible death--but there's no explicit
guarantee of that. I suppose that's fine (we are talking major WTFs
after all) in general, although it would be nice to have more control.
phkmalloc had more limit checking, so bad pointers (text / stack) were
reliably detected.

Worse, malloc_usable_size() fails if you pass it a pointer inside a
malloc'ed region. Again, you get an assert if that's enable, otherwise
you probably get a random value.
The reason for this is in arena_salloc, where the passed pointer is
compared to the calculated page, to determine whether we are dealing
with a small or large allocation.
Unfortunately, I don't see an easy fix for this.

Do you have any suggestion, or should I just give up on using
malloc_usable_size()?

As an aside: regardless of my purely educational exercise, what do you
guys think of putting such checks in the libc itself? The performance
impact is relatively small, and the benefits in terms of detecing and
preventing heap buffer overflows huge. That's all the more important
with jemalloc, which is (relatively) less safe that phkmalloc in fact
of such attacks.

Bye,
	Andrea

1: http://www.cs.umass.edu/~emery/pubs/06-28.pdf

-- 
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.
Received on Sun Sep 23 2007 - 09:34:45 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:18 UTC