From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/203 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: holywar: malloc() vs. OOM Date: Sun, 24 Jul 2011 09:27:04 -0400 Message-ID: <20110724132704.GK132@brightrain.aerifal.cx> References: <20110724103325.GA24069@albatros> <20110724124034.GI132@brightrain.aerifal.cx> <20110724132913.GH27634@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1311514675 14412 80.91.229.12 (24 Jul 2011 13:37:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 24 Jul 2011 13:37:55 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-287-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jul 24 15:37:52 2011 Return-path: Envelope-to: gllmg-musl@lo.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by lo.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1QkysR-00029R-Qp for gllmg-musl@lo.gmane.org; Sun, 24 Jul 2011 15:37:51 +0200 Original-Received: (qmail 24067 invoked by uid 550); 24 Jul 2011 13:37:51 -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 24055 invoked from network); 24 Jul 2011 13:37:51 -0000 Content-Disposition: inline In-Reply-To: <20110724132913.GH27634@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:203 Archived-At: On Sun, Jul 24, 2011 at 03:29:14PM +0200, Szabolcs Nagy wrote: > > > Probably I overestimate the importance of OOM errors, and (1) in > > > particular. However, I think it is worth discussing. > > > > I don't think you overestimate the importance of OOM errors. Actually > > Linux desktop is full of OOM errors that ruin usability, like file > > managers that hang the system for 5 minutes then crash if you navigate > > to a directory with a 15000x15000 image file. Unfortunately I don't > > think it's possible to fix at the libc level, and fixing the worst > > issues (DoS from apps crashing when they should not crash) usually > > involves both sanity-checking the size prior to calling malloc *and* > > checking the return value of malloc... > > what about providing an alternative libc or libcwrapper api I think this is definitely possible, probably just via -I/path/to/alt/stdlib/h and some inline code and macros in the stdlib.h there, along with #include_next , and it probably doesn't really need cooperation with libc (i.e. if it's written cleanly enough it would probably work with most libcs. > it could "fix" deprecated/dangerous calls > (maybe turn them into compiletime errors) > and things like oom failures into runtime errors > > so bad code can be compiled against this radical extremist libc The only problem I see is that it only catches "known bad" code. As an admin I would be inclined to simply look for another program that performs the function I need, rather than trying to compile in workarounds, if I knew a program had code that bad.. Rich