Date: Sun, 22 Dec 2013 23:46:09 -0500 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: Removing sbrk and brk On Sun, Dec 22, 2013 at 07:48:55PM +0100, Szabolcs Nagy wrote: > * Rich Felker <dalias@...ifal.cx> [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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.