[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 29 Jun 2019 12:49:45 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Conditional signal safety?
On Sat, Jun 29, 2019 at 07:54:05AM +0200, Markus Wichmann wrote:
> Hi all,
>
> at work yesterday I had to build an exception handler (a signal handler
> for SIGSEGV, SIGBUS, SIGILL, and SIGFPE). For my purposes, it was really
> convenient to just use dladdr() to find out at least what module and
> function PC and LR were pointing to when the exception happened, so I
> used that function.
This is convenient for debugging, but I would strongly discourage its
use in deployment. Attempts to intercept and introspectively report
(or even worse, patch up and continue after) memory-safety UB almost
always provide tools for an attacker to turn an unexploitable or
difficult-to-exploit error into one they can exploit. This is inherent
in continuing to run and make calls that might make use of compromised
pointers.
> Now, dladdr() is not on the list of signal safe functions, but then,
> dladdr() is a GNU extension. I wondered if it is signal safe and noticed
> that at least musl's implementation is, provided that dlopen() was not
> the function that was pre-empted. That got me thinking: Is there such a
> thing as "conditional signal safety"?
There's not, because it requires too fine-grained constraint of
implementation internals; my understanding is that this is the reason
both on the standards side (where they're rightfully opposed to
specifying anything about the interaction of internals) and on the
musl implementation side (where we don't want to preclude interactions
that have no obvious reason to exist but that are needed to fix subtle
problems -- see for example the interaction between sigaction and
abort).
> dladdr() takes a rwlock in read mode. At the moment, this means it can
> only block if the lock is write locked, which only dlopen() will ever
> do. dladdr() does nothing else that would impede signal safety. But of
> course, these are implementation details. What is actually defined about
> the interface?
Nothing further. Documenting the behavior of nonstandard extension
functions musl supports is on the agenda, but I don't think
documenting properties that are consequences of implementation
internals would be part of it except possibly as part of a "hacking"
document for use in debugging with tools that aren't stable interface
guarantees.
Rich
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.
