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 19406 invoked from network); 10 Jun 2020 00:58:44 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 10 Jun 2020 00:58:44 -0000 Received: (qmail 2018 invoked by uid 550); 10 Jun 2020 00:58:41 -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 1995 invoked from network); 10 Jun 2020 00:58:39 -0000 Date: Tue, 9 Jun 2020 20:58:26 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200610005825.GI1079@brightrain.aerifal.cx> References: <20200609035010.GE1079@brightrain.aerifal.cx> <20200609110914.GC871552@port70.net> <20200609200800.GG1079@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200609200800.GG1079@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] mallocng switchover - opportunity to test 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 [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