[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 1 Jul 2019 12:13:16 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Conditional signal safety?
On Mon, Jul 01, 2019 at 05:55:07PM +0200, Florian Weimer wrote:
> * Rich Felker:
>
> > On Mon, Jul 01, 2019 at 06:21:11AM +0200, Florian Weimer wrote:
> >> * Markus Wichmann:
> >>
> >> > 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.
> >>
> >> Are these signals generated synchronously, by running code? Then the
> >> rules regarding asynchronous signal safety do not apply.
> >
> > That's a meaningful distinction if they're generated by accesses in
> > the application code. If they're generated by accesses from within
> > standard library functions (e.g. because you passed an invalid pointer
> > or one to memory that was intentionally setup to generate them) to a
> > stdlib function, it's just UB, and if you were going to define it,
> > it'd still be an async signal context just because it's async with
> > respect to the interrupted state of the stdlib function being
> > unspecified/unspecifiable.
>
> Right, but if libc code traps without violating preconditions, that's
> generally a bug.
Yes. If any of these signals are generated in libc without the
preconditions of the interface having been violated, that's a bug in
libc. For appropriate notions of what the preconditions are. It's
clear for stuff like invalid pointers, but less obvious when you're
dealing with things like memory setup explicitly to trap. My view is
that such memory still does not constitute the regular C object the
function requires, and thus the standard doesn't define any behavior
for it. I think it would be hard to specify any particular behavior
without also specifying a lot of the library internals -- either you
have to specify that the signal context is an async one, or you have
to place constraints on how internal locking and resource usage works
and what locks can possibly be held by what interfaces.
So, IMO you have to treat it as "at best an async signal context; at
worst, UB and thereby completely undefined program state".
> And if you violate preconditions, than *that* already
> triggers undefined behavior, and not the trap later on. (For example,
> the compiler uses the knowledge of well-known functions and optimizes
> accordingly.)
Yes.
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.
