Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200809075430.GA10312@voyager>
Date: Sun, 9 Aug 2020 09:54:31 +0200
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: Revisiting sigaltstack and implementation-internal signals

On Sat, Aug 08, 2020 at 08:39:58PM -0400, Rich Felker wrote:
> on it (possibly not even any signal handlers installed), and (2)
> whether we should care about breaking code that swaps off of and back
> onto the alternate signal stack with swapcontext.

Would anything bad happen in that case? I thought, when a signal handler
with SA_ONSTACK is invoked, the altstack is marked with SS_ONSTACK and
will not be reset until the signal handler returns. If the handler does
not return, and does not call sigaltstack(), then the SS_ONSTACK remains
set, and therefore further signals with SA_ONSTACK will be delivered on
the current stack. Otherwise, if a signal were to arrive while the
altstack is in use, it would overwrite the old stack.

I cannot find a source code for swapcontext, but to my knowledge it
merely combines setjmp() and longjmp(), right? (setjmp() for the current
context and longjmp() for the other one). So no call to sigaltstack().

Ciao,
Markus

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.