[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180917111350.GU4418@port70.net>
Date: Mon, 17 Sep 2018 13:13:50 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Replacing a_crash() ?
* Rich Felker <dalias@...c.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..)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
