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.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 12559 invoked from network); 10 Aug 2020 00:28:36 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 10 Aug 2020 00:28:36 -0000 Received: (qmail 16215 invoked by uid 550); 10 Aug 2020 00:28:33 -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 16192 invoked from network); 10 Aug 2020 00:28:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dereferenced.org; s=default; t=1597019301; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=z1M943K8cJ7Th2bWpbS33/zNEqOhoa4NU3peDGXhekE=; b=FS56hF5JZV11MQro0Cn3LmtexuuQ3nXpTsOQEUxlZGFY/NndepJ9tjC3UGMqlQytc5c8Kb 5fsD4QbZauvY9voJZeW846JY35Quxsvk3DvWQXWC/OAif9eJrUHWjXR3JrtR+6rwooJ13W 9ofGhcYHMz/4q8FcRnHindlO41mEfUY= To: musl@lists.openwall.com References: <20200809003958.GE3265@brightrain.aerifal.cx> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Ariadne Conill Message-ID: Date: Sun, 9 Aug 2020 18:28:17 -0600 MIME-Version: 1.0 In-Reply-To: <20200809003958.GE3265@brightrain.aerifal.cx> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [musl] Revisiting sigaltstack and implementation-internal signals 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