[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200810154123.GC879655@port70.net>
Date: Mon, 10 Aug 2020 17:41:23 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: Olaf Flebbe <of@...ebbe.de>
Cc: musl@...ts.openwall.com
Subject: Re: Revisiting sigaltstack and implementation-internal signals
* Olaf Flebbe <of@...ebbe.de> [2020-08-10 10:15:13 +0200]:
> 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 .
this will fail if an application calls sigaltstack,
then blocks all user signals that are SA_ONSTACK and
then deallocates the stack passed to sigaltstack.
it is important to discuss what an application may
or may not do, because the proposed change observably
modifies the behaviour.
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.
