mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Ariadne Conill <ariadne@dereferenced.org>
To: musl@lists.openwall.com
Subject: Re: [musl] Revisiting sigaltstack and implementation-internal signals
Date: Sun, 9 Aug 2020 18:28:17 -0600	[thread overview]
Message-ID: <a2f155e5-d1e8-f039-65c3-11cffbb0ba3b@dereferenced.org> (raw)
In-Reply-To: <20200809003958.GE3265@brightrain.aerifal.cx>

Hello,

On 2020-08-08 18:39, Rich Felker wrote:
> It's come up again, via Go this time (see
> https://github.com/golang/go/issues/39857), 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
>      stack."
> 
> 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 seems like a reasonable position.

> 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.

In my opinion, mixing stacks with ucontext calls and sigaltstack is 
undefined behavior.  There is no way to guarantee the safety of such 
operations, or at least none that I can think of.

So personally, I think if people do that, they are basically asking for 
problems, and we have no obligation to fix those problems.

Ariadne

  parent reply	other threads:[~2020-08-10  0:28 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-09  0:39 Rich Felker
2020-08-09  7:54 ` Markus Wichmann
2020-08-10  0:06   ` Rich Felker
2020-08-10 16:34     ` Markus Wichmann
2020-08-10  0:10   ` Ariadne Conill
2020-08-10  0:26     ` Rich Felker
2020-08-10  0:28 ` Ariadne Conill [this message]
2020-08-10  8:15   ` Olaf Flebbe
2020-08-10 15:41     ` Szabolcs Nagy
2020-08-10 15:45       ` Olaf Flebbe
2020-08-10 16:24         ` Szabolcs Nagy
2020-08-10 16:27         ` Rich Felker
2020-08-10 16:36     ` Rich Felker
2020-08-10 16:57       ` Olaf Flebbe
2020-08-10 17:00         ` Rich Felker
2020-08-10 17:04           ` Olaf Flebbe
2020-08-10 18:32             ` Rich Felker
2020-08-10 19:29               ` Olaf Flebbe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a2f155e5-d1e8-f039-65c3-11cffbb0ba3b@dereferenced.org \
    --to=ariadne@dereferenced.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).