[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 10 Aug 2020 10:15:13 +0200
From: Olaf Flebbe <of@...ebbe.de>
To: musl@...ts.openwall.com
Subject: Re: Revisiting sigaltstack and implementation-internal signals
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@...eferenced.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
Content of type "text/html" skipped
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.
