mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Szabolcs Nagy <nsz@port70.net>
To: musl@lists.openwall.com
Subject: Re: Replacing a_crash() ?
Date: Mon, 17 Sep 2018 13:13:50 +0200	[thread overview]
Message-ID: <20180917111350.GU4418@port70.net> (raw)
In-Reply-To: <20180917032317.GF17995@brightrain.aerifal.cx>

* Rich Felker <dalias@libc.org> [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..)


  parent reply	other threads:[~2018-09-17 11:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-17  3:23 Rich Felker
2018-09-17  3:50 ` A. Wilcox
2018-09-17  9:24   ` u-uy74
2018-09-17 11:13 ` Szabolcs Nagy [this message]
2018-09-17 13:24   ` Rich Felker
2018-09-17 15:24 ` Markus Wichmann
2018-09-17 15:36   ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180917111350.GU4418@port70.net \
    --to=nsz@port70.net \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).