From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24525 invoked from network); 10 Aug 2020 16:57:40 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 10 Aug 2020 16:57:40 -0000 Received: (qmail 19606 invoked by uid 550); 10 Aug 2020 16:57:37 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 19588 invoked from network); 10 Aug 2020 16:57:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1597078645; s=strato-dkim-0002; d=oflebbe.de; h=Message-Id:In-Reply-To:To:References:Date:Subject:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=+VM9Yu80vJUj6qbKeh2CrHM6DYptb24AVz5E7UOP1jM=; b=p4DuqjKIHNNvj1SCNR3eGgDI3GGGj/3xSuKRaLj+ikrdOFnvFyPdHNIWvEGhLqP2Bk ZVGYwOWVxMMMs7l2I7AQgTuyT6J5q2ToypL+sRlsYjtz48rWHRh6R/vTLVUVIVqJvBT8 qGkoYlVWZLv0jCvOTjFZ5IC1dkajhbril987v4s2i6omdEqrdk1DL+5nenGt0RJ6DmlW O1YyN4R4v/w07ITxD5kCtUe9Ldqbti7x4eB3F5fwLXsD4plZDaR7sDyAp/OrrBZk3mpw 8NA8/M7A+vDa0QmiR3ytrc9JVID9Ml5BUmOP2+0cz+kmvBV8DcVcfOZxj/yq8XmqNXVl TIaw== X-RZG-AUTH: ":I2okekakfv3mKNs8YSFayssNXg+upDn7jErwclkPntL+Rbxoy1FyfmVPIbDECH82zNYb4zXt9RFJJgQXvGBS959f7VPVP3v3qQ==" X-RZG-CLASS-ID: mo00 From: Olaf Flebbe Content-Type: multipart/alternative; boundary="Apple-Mail=_0CC6C20B-46BF-4018-BF4C-A2CC5BF259B3" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Mon, 10 Aug 2020 18:57:21 +0200 References: <20200809003958.GE3265@brightrain.aerifal.cx> <2142D551-13BE-4033-94F7-80A7B2C01890@oflebbe.de> <20200810163647.GI3265@brightrain.aerifal.cx> To: musl@lists.openwall.com In-Reply-To: <20200810163647.GI3265@brightrain.aerifal.cx> Message-Id: X-Mailer: Apple Mail (2.3608.120.23.2.1) Subject: Re: [musl] Revisiting sigaltstack and implementation-internal signals --Apple-Mail=_0CC6C20B-46BF-4018-BF4C-A2CC5BF259B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Rick , While the alternate stack is in use on cannot change the alternate = stack. See https://pubs.opengroup.org/onlinepubs/9699919799/=20 EPERM Error. Olaf > Am 10.08.2020 um 18:36 schrieb Rich Felker : >=20 > On Mon, Aug 10, 2020 at 10:15:13AM +0200, Olaf Flebbe wrote: >> Hi,=20 >>=20 >> I have some problems to follow the discussion here. >>=20 >> 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. >>=20 >> I am proposing smthg like >>=20 >> --- /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 =3D { .sa_flags =3D SA_RESTART, .sa_handler = =3D handler }; >> + struct sigaction sa =3D { .sa_flags =3D SA_RESTART|SA_ONSTACK, = ..sa_handler =3D handler }; >> pthread_t self =3D __pthread_self(), td; >> int count =3D 0; >>=20 >> This will fix the problem with dynamic stacks, like go implements it.=20= >> 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). >=20 > It's fundamental, since presence and identity of an alternate stack > are thread-local properties and SA_ONSTACK is global to the signal > disposition. >=20 > 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.) >=20 > 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. >=20 > Rich --Apple-Mail=_0CC6C20B-46BF-4018-BF4C-A2CC5BF259B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Rick ,

While the = alternate stack is in use on cannot change the alternate = stack.

See https://pubs.opengroup.org/onlinepubs/9699919799/ 
EPERM Error.

Olaf


Am 10.08.2020 um 18:36 schrieb Rich Felker <dalias@libc.org>:

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 =3D { = .sa_flags =3D SA_RESTART, .sa_handler =3D handler };
+ struct = sigaction sa =3D { .sa_flags =3D SA_RESTART|SA_ONSTACK, ..sa_handler =3D = handler };
pthread_t self =3D = __pthread_self(), td;
int count =3D 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

= --Apple-Mail=_0CC6C20B-46BF-4018-BF4C-A2CC5BF259B3--