From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14391 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker 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 17:48:07 -0400 Message-ID: <20190710214807.GY1506@brightrain.aerifal.cx> References: <20190709193004.GQ1506@brightrain.aerifal.cx> <20190710183931.GT1506@brightrain.aerifal.cx> <20190710212319.GM21055@port70.net> 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="222205"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14407-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 10 23:48:23 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 1hlKRq-000vhB-Pd for gllmg-musl@m.gmane.org; Wed, 10 Jul 2019 23:48:22 +0200 Original-Received: (qmail 7268 invoked by uid 550); 10 Jul 2019 21:48:20 -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 7250 invoked from network); 10 Jul 2019 21:48:20 -0000 Content-Disposition: inline In-Reply-To: <20190710212319.GM21055@port70.net> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14391 Archived-At: On Wed, Jul 10, 2019 at 11:23:19PM +0200, Szabolcs Nagy wrote: > * 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. Yes. Also, in musl, we generally document motivations like this as part of commit messages rather than comments. This ties them to the timeline of changes, to the author, and prevents them from sticking around when code changes and they no longer make sense. James, could you submit this patch just as the minimal change to correct the current bug? If additional documentation of why things are the way they are is needed that can be done separately. > 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. In this case it's more that the kernel values are just wrong. libc isn't imposing a stronger limit here because of libc code needing stack, but because the kernel values don't account for signal frame size. The kernel values presumably can't be changed because the syscall interface is stable/locked, and it's risky to change for libc too after it's set (see the issue with whether the x86 values are right in the presence of AVX512 -- that's why on later archs we imposed stronger limits). Rich