Re: [musl] mallocng switchover - opportunity to test

[Szabolcs Nagy <nsz@port70.net>]

* 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.)

fyi, i looked at enabling AArch64 MTE in malloc ng, with the
current linux syscall abi patches i saw the following issues:

- brk is not usable (this might change in the final linux patches
  but it's nice that we can turn brk usage off in malloc-ng)

- reclaim_gaps is not usable (in linux, file content may be in
  memory that does not support mte, even for private CoW maps,
  this can be changed in principle but to use reclaim_gaps elf
  changes will be needed anyway so a loader knows it has to
  use PROT_MTE and there is no elf abi design for that yet)

- meta data at the end of an allocation slot cannot share the
  same tagging granule (16byte) with user allocation (otherwise
  accessing it would become akward due to possible concurrent
  tag changes, even if we don't care about protecting that meta
  data with mte) hence 16 bytes has to be reserved for meta data,
  this impacts the overhead of small allocations (the required
  code change is small given it already uses 16byte units, but
  since the layout of allocations is affected this is probably
  the most intrusive change mte requires).

- madvise MADV_FREE means naive tagging of internal/freed memory
  with a reseved internal tag does not work: internal pointers
  cannot access memory after they are zeroed by the kernel.
  this can be fixed in various ways i haven't decided what's
  best yet. enabling mte will cause various regressions and
  different behaviour (e.g. because all pages are written to on
  malloc, calloc, realloc, free) this will be one of them.

if support for this is interesting i can work on patches
that can be upstreamed (e.g. macros conditional on mte
support etc)