On Mon, Aug 28, 2006 at 02:03:25AM -0400, John Moser wrote:
> I'm writing my own memory allocator here and have come up with a very
> simple design. I'm wondering if there's anything useful I've missed; I
> know the basic ideas behind OpenBSD and glibc allocators but I don't
> have their architecture in front of me.
>
> The goal is to do a minimal allocator (i.e. very little code) that gives
> good security, performance, and resource management (I hate things
> bloating to 3 times bigger than needed).
>
> Mine's got a few features:
> I'm also considering other features:
>
> - The simple addition of prescribble/postscribble option.
> Prescribbling would fill memory with 0xaa when allocated; while
> postscribbling would fill it with 0x55 after free(). This would
> cause failure when making bad assumptions about freshly malloc()'d
> memory or when accessing free()d segments.
>
> - Post-xcanary. Enforce allocations to be considered of length
> (control_data + data + xcanary), such that the xcanary in the
> control_data and the xcanary after the last byte would be the same.
> Writes one beyond the end of micro-tier allocated pages would destroy
> the canary and get detected next time a malloc(), realloc(), or
> free() interacted with that allocation.
>
> The design I've chosen is a micro-tier design based on glibc's handling
> of large allocations. glibc allocates 128K or larger allocations using
> mmap(); 128KiB+1B wastes 4095 bytes (on 4K page systems), roughly 1/32
> of the allocated memory. As long as only 1/32 of the physical memory is
> wasted, allocating with mmap() should be sane. Note that the number
> chosen is rather arbitrary and can be tightened or loosened to taste;
> OpenBSD for example would be this design at 1/2 (anything over a page
> gets mmap() in OBSD, and can only waste 50%).
>
> The inspiration from OpenBSD for guard pages leads me to the
> high-aligned allocations in macro-tier pages, allowing me to
> artificially create segfaults where normal allocators wouldn't be able
> to enforce proper behavior. Failing this immediate retribution in
> micro-tier allocations, which pack multiple allocations into a 256K
> mmap() segment, the post-xcanary idea will probably allow for detection
> of off-by-one at a later date.
>
> Did I miss anything important?
I'm far from an expert in such matters, but some random thoughts from
someone who did only once ever try to build something like this (and
thought better of it soon enough):
1. Most systems have a pretty sane malloc() implementation,
which can be tuned to the underlying system. Thus, it's hard to beat
malloc().
2. OpenBSD's MALLOC_OPTIONS is very useful in debugging, very
easy to turn on if required, and means that the more aggressive
debugging stuff doesn't take CPU time when not required. It's a very
good idea, and you'd do well to borrow it.
On this same note, some more options for debugging would be
useful, if not necessarily required.
3. I'm fairly certain the OpenBSD allocator takes pains to
prevent any more page faults than necessary; i.e., the allocated pages
are not written to, as much as possible. I can't tell either way from
the above description.
4. Referencing (3), allocating too many pages doesn't really
hurt all that much. Allocating too much memory that's actually used is
annoying, though.
Joachim
