From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13279 Path: news.gmane.org!.POSTED!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Replacing a_crash() ? Date: Mon, 17 Sep 2018 13:13:50 +0200 Message-ID: <20180917111350.GU4418@port70.net> References: <20180917032317.GF17995@brightrain.aerifal.cx> 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 1537182719 26857 195.159.176.226 (17 Sep 2018 11:11:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 17 Sep 2018 11:11:59 +0000 (UTC) User-Agent: Mutt/1.9.1 (2017-09-22) To: musl@lists.openwall.com Original-X-From: musl-return-13295-gllmg-musl=m.gmane.org@lists.openwall.com Mon Sep 17 13:11:55 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 1g1rRa-0006t7-60 for gllmg-musl@m.gmane.org; Mon, 17 Sep 2018 13:11:54 +0200 Original-Received: (qmail 9262 invoked by uid 550); 17 Sep 2018 11:14:02 -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 9244 invoked from network); 17 Sep 2018 11:14:02 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20180917032317.GF17995@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:13279 Archived-At: * 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..)