Hi, 

I have some problems to follow the discussion here.

It is not about musl to create an alternate stack, it is to *honor* the alternate stack, if the application installed one, for a reason.

I am proposing smthg like

--- /oss/musl-1.2.1/src/thread/synccall.c
+++ /work/musl/src/thread/synccall.c
@@ -45,7 +45,7 @@
 {
  sigset_t oldmask;
  int cs, i, r;
- struct sigaction sa = { .sa_flags = SA_RESTART, .sa_handler = handler };
+ struct sigaction sa = { .sa_flags = SA_RESTART|SA_ONSTACK, .sa_handler = handler };
  pthread_t self = __pthread_self(), td;
  int count = 0;

 

This will fix the problem with dynamic stacks, like go implements it. 
If the application does not install one, kernel will ignore SA_ONSTACK. (This is even specified by POSIX, since there is no error condition mentioned in man page specifically for this).

Tested with go and a glibc threaded setuid test tst-setuid3.c .

Best,
Olaf


Am 10.08.2020 um 02:28 schrieb Ariadne Conill <ariadne@dereferenced.org>:

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