From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/202 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: holywar: malloc() vs. OOM Date: Sun, 24 Jul 2011 15:29:14 +0200 Message-ID: <20110724132913.GH27634@port70.net> References: <20110724103325.GA24069@albatros> <20110724124034.GI132@brightrain.aerifal.cx> 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 1311514170 11875 80.91.229.12 (24 Jul 2011 13:29:30 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 24 Jul 2011 13:29:30 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-286-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jul 24 15:29:26 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 1QkykI-0008Lw-OQ for gllmg-musl@lo.gmane.org; Sun, 24 Jul 2011 15:29:26 +0200 Original-Received: (qmail 19811 invoked by uid 550); 24 Jul 2011 13:29:26 -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 19803 invoked from network); 24 Jul 2011 13:29:26 -0000 Content-Disposition: inline In-Reply-To: <20110724124034.GI132@brightrain.aerifal.cx> User-Agent: Mutt/1.5.20 (2009-06-14) Xref: news.gmane.org gmane.linux.lib.musl.general:202 Archived-At: * Rich Felker [2011-07-24 08:40:34 -0400]: > On Sun, Jul 24, 2011 at 02:33:25PM +0400, Vasiliy Kulikov wrote: > > But looking at the problem from the pragmatic point of view we'll see > > that libc is actually the easiest place where the problem may be > > workarounded (not fixed, surely). The workaround would be simply > > raising SIGKILL if malloc() fails (either because of brk() or mmap()). > > For the rare programs craving to handle OOM such code should be used: > > This is absolutely wrong and non-conformant. It will also ruin all > A better solution might be to have a gcc option to generate a read > from the base address the first time a function performs arithmetic on > a pointer it has not already checked. This is valid because the C sounds reasonable > > 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 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 i guess for now running code under valgrind can catch most of these issues..