Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sat, 8 Aug 2020 20:39:58 -0400
From: Rich Felker <>
Subject: Revisiting sigaltstack and implementation-internal signals

It's come up again, via Go this time (see, that it would be nice to
have musl use the alternate signal stack for implementation-internal
signals. I've previously wanted to do this, but been unclear on (1)
whether it's permissible for the implementation to touch the
application-provided alternate stack when there is no signal delivered
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.

In regards to question (1), I believe this language from the
specification of sigaltstack is sufficient to resolve it:

    "The range of addresses starting at ss_sp up to but not including
    ss_sp+ ss_size is available to the implementation for use as the

I read "available to the implementation" as implying that the
application can make no assumptions about values previously stored in
the memory being retained.

This still leaves (2) open, as well as whether there are any other
reasons why we shouldn't have implementation-internal signals using
the alternate stack.


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.