From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31652 invoked from network); 9 Jun 2020 11:09:30 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 9 Jun 2020 11:09:30 -0000 Received: (qmail 30540 invoked by uid 550); 9 Jun 2020 11:09:28 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 30519 invoked from network); 9 Jun 2020 11:09:27 -0000 Date: Tue, 9 Jun 2020 13:09:14 +0200 From: Szabolcs Nagy To: Rich Felker Cc: musl@lists.openwall.com Message-ID: <20200609110914.GC871552@port70.net> Mail-Followup-To: Rich Felker , musl@lists.openwall.com References: <20200609035010.GE1079@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200609035010.GE1079@brightrain.aerifal.cx> Subject: Re: [musl] mallocng switchover - opportunity to test * Rich Felker [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)