From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4409 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Removing sbrk and brk Date: Sun, 22 Dec 2013 23:46:09 -0500 Message-ID: <20131223044609.GZ24286@brightrain.aerifal.cx> References: <20131221234041.GA13204@brightrain.aerifal.cx> <20131222184855.GS1685@port70.net> 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 1387773977 32756 80.91.229.3 (23 Dec 2013 04:46:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Dec 2013 04:46:17 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4413-gllmg-musl=m.gmane.org@lists.openwall.com Mon Dec 23 05:46:24 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 1VuxPM-0006dd-9j for gllmg-musl@plane.gmane.org; Mon, 23 Dec 2013 05:46:24 +0100 Original-Received: (qmail 15719 invoked by uid 550); 23 Dec 2013 04:46:23 -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 15709 invoked from network); 23 Dec 2013 04:46:22 -0000 Content-Disposition: inline In-Reply-To: <20131222184855.GS1685@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4409 Archived-At: On Sun, Dec 22, 2013 at 07:48:55PM +0100, Szabolcs Nagy wrote: > * 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 In principle, there's no rule that AS-safe interfaces can't use malloc. As one special case, if signal/sigaction has never been called, you can't be in an AS context, so malloc could be used freely. Other means of detection may also be possible. Unless sbrk were _specified_ (in the documentation of this legacy/nonstandard function) as safe to use as long as you stick to only AS-safe functions, I don't see how applications could use it safely even then. FYI the dynamic linker also uses malloc but I don't see a way this could be dangerous to such apps unless you're using dlopen too. > sbrk(0) is a valid usage and i think that's common (eventhough it is > mostly useless) Mostly useless I agree, but I worry that some things might gratuitously break if it doesn't work... > > - 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) As far as I'm aware, sbrk/brk are the only ones that can _never_ be used safely. Even gets _can_ be used safely, e.g. if stdin is a pipe from a related process and you know the max line length you will encounter. > another solution is to split libc into libgood and libbad > (or mark the broken apis in some way to catch their usage easily) There are various GCC-specific ways in the headers such as the deprecated attribute and poison pragma. These could be utilized with -include or a special -I path and #include_next. > .... > > 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 I agree mostly. Option 5 would be ideal, but it depends on determining whether there would be detrimental affects on performance. Even if there are, however, it may be acceptable since I eventually want to drop the madvise-based approach to returning memory to the kernel, which doesn't relinquish any commit charge, and replace it with PROT_NONE... For now though it seems we're trying to decide between options 1 and 3. If we go for option 1, we should fix the integer overflow/wrapping issue in sbrk you reported on irc.. Rich