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