Re: [musl] mallocng switchover - opportunity to test

[Rich Felker <dalias@libc.org>]

On Tue, Jun 09, 2020 at 04:08:00PM -0400, Rich Felker wrote:
> On Tue, Jun 09, 2020 at 01:09:14PM +0200, Szabolcs Nagy wrote:
> > * Rich Felker <dalias@libc.org> [2020-06-08 23:50:10 -0400]:
> > > This produces a near-fully-integrated malloc, including support for
> > > reclaim_gaps donation from ldso. The only functionality missing, which
> > > I expect to flesh out before actual import, is handling of the case of
> > > incomplete malloc replacement by interposition (__malloc_replaced!=0).
> > 
> > i would actually prefer if we didn't check for __malloc_replaced
> > in aligned alloc, because i think it does not provide significant
> > safety, but it prevents the simple RTLD_NEXT wrappers which are
> > commonly used for simple malloc debugging/tracing/etc (and while
> > unsafe in general depending on what libc api calls they make,
> > they likely work in practice).
> > 
> > (the check does not provide safety because existing interposers
> > written for glibc likely work with musl too without issues:
> > the only problem is if musl uses aligned alloc somewhere where
> > glibc does not so an interposer may work on glibc without
> > interposing aligned alloc but not on musl. for newly written
> > interposers we just need to document the api contract.)
> 
> I'm not sure about this, and how it interacts with our definition of
> posix_memalign and memalign in terms of aligned_alloc.

What do you think of this proposal:

Have ldso track both whether malloc was replaced and whether
aligned_alloc was replaced. If malloc was replaced but aligned_alloc
wasn't, aligned_alloc fails with ENOMEM. If both were replaced and our
internal aligned_alloc still gets called, assume some sort of wrapping
is going on and allow it to proceed.

With mallocng, this is "safe" against misuse in the sense that it will
trap rather than corrupting memory if the contract is violated.

Rich