From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13280 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Replacing a_crash() ? Date: Mon, 17 Sep 2018 09:24:28 -0400 Message-ID: <20180917132428.GG17995@brightrain.aerifal.cx> References: <20180917032317.GF17995@brightrain.aerifal.cx> <20180917111350.GU4418@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1537190558 2481 195.159.176.226 (17 Sep 2018 13:22:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 17 Sep 2018 13:22:38 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13296-gllmg-musl=m.gmane.org@lists.openwall.com Mon Sep 17 15:22:34 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1g1tU0-0000XE-T2 for gllmg-musl@m.gmane.org; Mon, 17 Sep 2018 15:22:32 +0200 Original-Received: (qmail 1926 invoked by uid 550); 17 Sep 2018 13:24:41 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1908 invoked from network); 17 Sep 2018 13:24:41 -0000 Content-Disposition: inline In-Reply-To: <20180917111350.GU4418@port70.net> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13280 Archived-At: On Mon, Sep 17, 2018 at 01:13:50PM +0200, Szabolcs Nagy wrote: > * Rich Felker [2018-09-16 23:23:17 -0400]: > > Now that we have an abort() that reliably terminates with uncatchable > > SIGABRT, I've been thinking about replacing the a_crash() calls in > > musl (which are usually an instruction generating SIGILL or SIGSEGV) > > with calls to the uncatchable tail of abort(), which I would factor > > off as a __forced_abort() function. > > > > In case it's not clear, the reason for not just calling abort() is > > that too many programs catch it, and catching it is even encouraged. > > Catchability is a problem with the current approach too, since > > a_crash() is used in places where process state is known to be > > dangerously corrupt and likely under attacker control; eliminating it > > is one of the potential goals of switching to __forced_abort(). > > i wonder if it can be made debugging friendly in some way, > e.g. with multiple failure paths merged into a single > __forced_abort call or when it's tail called, it may > not be clear from a core dump why the abort happened. > > if __forced_abort(const char *reason) stored its argument > somewhere that is not clobbered then it may be easier to > figure out what went wrong. (you would still need some > debug skills to look at the reason though..) I think gcc already does something to make _Noreturn functions easier to debug like this, doesn't it? There's really not much advantage to a tail call when the function won't return. Rich