[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190305155719.GO23599@brightrain.aerifal.cx>
Date: Tue, 5 Mar 2019 10:57:19 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: sigaltstack for implementation-internal signals?
It came up recently that some erlang component is doing awful hacks
(see https://twitter.com/RichFelker/status/1099816400036773888) to try
to get implementation-internal signals to run on the alternate stack
setup by sigaltstack instead of the main stack. This desire makes some
sense, as they have tons of really tiny stacks and for their
coroutine-like things that rapidly context-switch in userspace. And
since there's no portable or valid way to do this hack, it raised the
issue for me: should we just always deliver implementation-internal
signals on the alternate stack if it's setup?
Unfortunateley I don't think this is possible/safe, for reasons
related to how the kernel's signal frame setup works. When a signal is
delivered and is to be handled on the alt stack, Linux checks whether
the current stack pointer is already on the alt stack. If so, it
decrements it normally; if not, it sets the stack pointer to the
beginning of the alt stack. The first case is needed in case a signal
interrupts a signal handler already running on the alt stack; if it
weren't handled that way, the second one would clobber the first one's
state, and upon return Bad Things would happen.
Unfortunately, this can go wrong. Suppose the application's signal
handler running on the alt stack changes the stack pointer to
something off the alt stack -- for example, using swapcontext, or some
awful split-stack hack. This is known to be "unsafe" in general, and
was the motivation for the (problematic with respect to POSIX, but
fixed in http://austingroupbugs.net/view.php?id=1187) addition of
SS_AUTODISARM. However, in principle it was "already safe" (without
SS_AUTODISARM) to use swapcontext with sigaltstack if the signal
handler and swapped-to context kept all SA_ONSTACK-flagged signals
blocked for their duration. An application could clearly arrange for
this; for example it's fairly natural if you only use one signal
handler that's SA_ONSTACK.
If we add unblockable, implementation-internal signals that are
flagged SA_ONSTACK, however, this breaks; now even if an application
has taken the "proper precautions", they can be delivered in a state
where the alt stack is nonempty but the stack pointer doesn't point
into it, thereby causing it to get clobbered.
Perhaps there's a chance that this just isn't supported/valid usage,
that "leaving the alt stack" should always be seen as abandoning it,
and that anything that worked before to preserve it was "just by
mistake/luck".
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.
