From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12690 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: tcmalloc compatibility Date: Tue, 10 Apr 2018 14:39:03 -0400 Message-ID: <20180410183903.GH3094@brightrain.aerifal.cx> References: <0ea267bf-ea3a-9810-be1a-50e71b6cfce1@denis.im> <20180410143359.GF3094@brightrain.aerifal.cx> <878t9vlzh1.fsf@mid.deneb.enyo.de> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1523385440 31920 195.159.176.226 (10 Apr 2018 18:37:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 10 Apr 2018 18:37:20 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12706-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 10 20:37:15 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1f5y8m-00088D-CF for gllmg-musl@m.gmane.org; Tue, 10 Apr 2018 20:37:12 +0200 Original-Received: (qmail 28073 invoked by uid 550); 10 Apr 2018 18:39:19 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 28055 invoked from network); 10 Apr 2018 18:39:18 -0000 Content-Disposition: inline In-Reply-To: <878t9vlzh1.fsf@mid.deneb.enyo.de> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12690 Archived-At: On Tue, Apr 10, 2018 at 07:53:46PM +0200, Florian Weimer wrote: > * Rich Felker: > > > malloc interposition is undefined behavior (as is any interposition of > > standard functions), and is very difficult to actually support as an > > extension in a way that doesn't have lots of serious problems. This > > has been discussed before but I don't have links handy. I'll try to > > dig them up later. The glibc folks are also aware that it's broken (on > > glibc, it only works if you get lucky and follow unwritten rules) > > We have some documentation nowadays: > > Thanks. This is useful information. I'm a bit concerned about the status of memalign, etc. though as described there. If malloc is replaced but the memalign family is not, calls to whichever function is not replaced will either use the system malloc (producing a result that's unsafe to pass to free) or will call the interposed malloc then assume they can doctor its book-keeping structures as if they matched the system malloc. Neither of these is safe. In musl, what we should probably do is have extra weak+hidden aliases, so that memalign can do something like: if (malloc != __internal_malloc) return 0; Maybe something similar would be appropriate in glibc? > The remaining undocumented aspects concern cyclic dependencies, such > as the suitability of certain TLS models for implementing a custom > malloc, or using memory-allocating glibc functions such as fopen or > backtrace from the allocator itself. > > In practice, The "in practice" here imposes strong constraints on implementation internals -- things could stop working at any time in the future if changes are made to ways/places in which malloc can be called. This could especially bite glibc if further alloca/large stack usage is replaced with malloc. > malloc interposition works extremely well and causes few > issues due to interposition itself. Obviously, there are bugs, but > most of them would still be bugs if the allocator was non-interposing. > (Examples are lots of initial-exec TLS data, and incorrect alignment > for allocations.) > > I believe musl uses less malloc internally, so it should be even more > compatible with an interposing malloc implementation than glibc. Indeed. But while musl uses less malloc, it also tries to be more opaque and provide fewer guarantees about implementation internals, leaving more free to change. There are some functions that musl makes AS-safe, beyond what POSIX requires, where I intended for the safety to actually be a public property, and I think those would be a good basis for what's allowed to be called from a malloc implementation, if we actually take the effort to document them. This would include a lot of useful things like dprintf, snprintf, mutex lock and (non-robust-type) unlock, semaphore wait (post is already AS-safe by POSIX), ... Unfortunately it doesn't even include mmap/munmap right now, due to tricks we're doing to work around the unsafety (inherent race conditions) in Linux's robust mutex support (I think glibc bug #14485 is related). I don't think this actually affects malloc though, and mmap/munmap could just be explicitly allowed for use in malloc even without documenting them as AS-safe. I think allowing any use of stdio (meaning functions that actually operate on FILEs, not counting snprintf, etc.) from malloc is a bad idea. Some functions (getline/getdelim) use malloc and some FILE types will necessarily (memstream) or potentially (cookie) involve malloc in potentially complex ways. A more interesting question is whether pthread functions, especially pthread_create (e.g. background thread managing migration between heaps) are permissible. They seem useful but also hard to guarantee safe to use in this context. Rich