[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131223044609.GZ24286@brightrain.aerifal.cx>
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.
