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.3 required=5.0 tests=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 22221 invoked from network); 10 Aug 2020 16:37:04 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 10 Aug 2020 16:37:04 -0000 Received: (qmail 7858 invoked by uid 550); 10 Aug 2020 16:37:00 -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 7840 invoked from network); 10 Aug 2020 16:36:59 -0000 Date: Mon, 10 Aug 2020 12:36:47 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200810163647.GI3265@brightrain.aerifal.cx> References: <20200809003958.GE3265@brightrain.aerifal.cx> <2142D551-13BE-4033-94F7-80A7B2C01890@oflebbe.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2142D551-13BE-4033-94F7-80A7B2C01890@oflebbe.de> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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