[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200810163647.GI3265@brightrain.aerifal.cx>
Date: Mon, 10 Aug 2020 12:36:47 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Revisiting sigaltstack and implementation-internal signals
On Mon, Aug 10, 2020 at 10:15:13AM +0200, Olaf Flebbe wrote:
> 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).
It's fundamental, since presence and identity of an alternate stack
are thread-local properties and SA_ONSTACK is global to the signal
disposition.
The behavior we're concerned about this alterring is not the case
where an application does not install an alternate stack; of course
that's unaffected. The interesting case is where an application does
install one, but expects (albeit IMO wrongly; that's what we're trying
to establish) that the stack memory is not touched/clobbered unless
there's actually an SA_ONSTACK signal handler present to run on it and
such a signal arrives. With the proposed change, the memory for the
alternate stack can be clobbered asynchronously with no such signal
handler existing. (In case it's not clear, the above code is *not a
signal handler* from the perspective that's relevant; it's an
implementation detail internal to the implementation.)
One way such clobbering could manifest is when a signal handler
running on the alternate stack temporarily moves the stack pointer to
somewhere else (not on the alternate stack), via swapcontext or some
other method. In this case, if a signal for cancellation or synccall
arrives, the kernel will consider the alt stack not in use, and will
start using it again from the beginning, clobbering the still-running
frames.
Rich
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.
