From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4407 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Removing sbrk and brk Date: Sun, 22 Dec 2013 19:48:55 +0100 Message-ID: <20131222184855.GS1685@port70.net> References: <20131221234041.GA13204@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1387738141 22296 80.91.229.3 (22 Dec 2013 18:49:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Dec 2013 18:49:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4411-gllmg-musl=m.gmane.org@lists.openwall.com Sun Dec 22 19:49:08 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Vuo5M-000505-8x for gllmg-musl@plane.gmane.org; Sun, 22 Dec 2013 19:49:08 +0100 Original-Received: (qmail 20375 invoked by uid 550); 22 Dec 2013 18:49:07 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 20367 invoked from network); 22 Dec 2013 18:49:07 -0000 Content-Disposition: inline In-Reply-To: <20131221234041.GA13204@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4407 Archived-At: * Rich Felker [2013-12-21 18:40:41 -0500]: > As far as I can tell, the only remotely legitimate use for sbrk/brk is > for applications to provide their own malloc implementation using it. single-threaded static linked binaries may want to avoid pulling in the entire malloc implementation with locks etc and use sbrk instead (i know some plan9 tools did this), i guess that should work if only async-signal-safe libc calls are used (those cannot use malloc or brk internally), but i don't think this is common sbrk(0) is a valid usage and i think that's common (eventhough it is mostly useless) > - making them always-fail > - making the headers break use of them > - completely removing the symbols > > The latter options are in some ways preferable, since the failure > would be caught at build-time and the program could be patched (or > different configure options passed) to fix the incorrect sbrk usage. i think there is a general problem of dangerous/broken/legacy interfaces i would prefer a separate tool that can catch these at compile-/run-time rather than fixing them in the libc (sbrk/brk are special because they are almost always wrong while the other broken interfaces are possible to use without invoking ub) another solution is to split libc into libgood and libbad (or mark the broken apis in some way to catch their usage easily) ... > However this option would definitely be a post-1.0 development > direction, and not something we could do right away (of course I'd > probably hold off until after 1.0 for any of these changes since > they're fairly invasive, except possibly the idea of making sbrk > always-fail). so the options in increasing effort are 1) leave it as is 2) completely remove sbrk/brk 3) always fail (except for sbrk(0)) 4) emulate with mmap+mprotect 5) malloc without brk i like 1) or 3) for 1.0 and 5) for post-1.0