[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 8 Aug 2014 15:57:58 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Replacing malloc
* Alexander Monakov <amonakov@...ras.ru> [2014-08-08 16:15:29 +0400]:
> On Fri, 8 Aug 2014, Rich Felker wrote:
> > The fourth issue is much bigger: replacing malloc is UB and does not
> > work, especially not on musl. :-)
>
> Whoa. Let me ask for further clarifications.
>
> You probably don't need me to tell you that most people expect that replacing
> malloc would in fact work, with at least two use cases in mind: a tracking
> wrapper around libc malloc (obtained via dlsym), or an entire custom allocator
> that obtains fresh memory via mmap. So you can LD_PRELOAD a "malloc
> debugging library" or preload or even link against an alternative allocator.
>
> Of course it's not without inherent issues. If the alternative allocator
> provides malloc/realloc/calloc/free, it's going to see an unexpected but
> legitimate free when the application passes pointer obtained via
> posix_memalign. Or when the application obtains a free()-able pointer via
> other libc functionality such as asprintf and the libc is linked in such a way
> that internal malloc calls are not interposable. Or on glibc a malloc wrapper
> needs to handle malloc->dlsym->malloc recursion.
i think the point is that all these issues are libc internals
and the application shouldnt know about the details and libc
should be free to change them without prior notice
> I hope above you didn't mean to say that anybody wishing to use malloc
> wrappers or custom mmap-based malloc replacements on musl should abandon all
> hope, period; but merely that it is not for production use, and attempting to
> do so should be with care, for instance if gnash library uses custom malloc,
> it may not return pointers to that memory to be free()'d by the main
> executable (calling libc's free). But it would be like that on any libc. So
> I have to wonder what "especially not on musl" stands for.
>
musl is linked with -Bsymbolic-functions so internally uses
its own malloc which avoids a lot of issues (it can internally
rely on its own malloc behaviour), but can cause problems when
external and internal alloc is mixed as you noted
(ie strdup, strndup, wcsdup, posix_memalign, aligned_alloc,
valloc, asprintf, vasprintf,.. pointers are passed to free,
the list may change in future, eg reallocarray was proposed)
external alloc must not use brk (it will collide with the internal
brk usage) and on some systems brk is the only way to access most
of heap memory (iirc on arm with default kernel settings and default
RLIMIT_DATA half of the address space is not available to mmap)
theoretically a libc implementation is allowed to handle the 'malloc'
symbol specially so usual linking rules do not apply (eg musl could
#define malloc __musl_malloc_v1 in the headers but leave free as is)
theoretically the libc may use malloc to implement mmap, dlsym etc
(although mmap is used in async-signal-safe contexts in practice..)
> But so far every time I speak about a problem with musl the problem is
> deeper than I initially think -- so please clarify :)
>
> Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
