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.