From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14389 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] Fix the use of sigaltstack to return to the saved main stack. Date: Wed, 10 Jul 2019 23:23:19 +0200 Message-ID: <20190710212319.GM21055@port70.net> References: <20190709193004.GQ1506@brightrain.aerifal.cx> <20190710183931.GT1506@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="122251"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-14405-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 10 23:23:35 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hlK3q-000VhF-Fg for gllmg-musl@m.gmane.org; Wed, 10 Jul 2019 23:23:34 +0200 Original-Received: (qmail 9768 invoked by uid 550); 10 Jul 2019 21:23:31 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 9745 invoked from network); 10 Jul 2019 21:23:31 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:14389 Archived-At: * James Y Knight [2019-07-10 16:11:23 -0400]: > int sigaltstack(const stack_t *restrict ss, stack_t *restrict old) > { > + // We must check requirements which Linux fails to verify in the syscall > + // itself. > if (ss) { > - if (ss->ss_size < MINSIGSTKSZ) { > + // The syscall does already check against MINSIGSTKSZ, however, > + // the kernel's value is smaller than musl's value on some > + // architectures. Thus, although this check may appear > + // redundant, it is not. the comment does not make sense to me, the check is obviously not redundant. MINSIGSTKSZ is a libc api, has nothing to do with the kernel the kernel also defines a MINSIGSZTKSZ but musl is an abstraction layer higher, the linux limit should not be observable to users, only the limit defined by musl, which ensures not only that the kernel can deliver a signal but also reserves space of any current or future hackery the c runtime may need to do around signal handling, so that trivial c language signal handler is guaranteed to work. this is the only reasonable way to make such limit useful. if it were only a kernel limit, then application code would have to guess the libc signal handling overhead and add that to the MINSIGSZTKSZ when allocating signal stacks.