[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200609110914.GC871552@port70.net>
Date: Tue, 9 Jun 2020 13:09:14 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: mallocng switchover - opportunity to test
* Rich Felker <dalias@...c.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)
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.
