From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27614 invoked by alias); 16 Jan 2019 22:51:15 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 27493 invoked by uid 89); 16 Jan 2019 22:51:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=fashion, HX-Envelope-From:sk:christi X-HELO: mail-wr1-f53.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brauner.io; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=X/M0lS0YkN0ccxw0ZN6RCQAnID7HLS5G3FBG3G5Ncyw=; b=Iole1Z1FRMH/tJdGiuiBJEHxIR5ctQWYLZOhr8n3ZIafCMkL1+fzAXJV/PhEvAku1S Oqc+CpSHBHIzXp/y/uhI8P9qNEpkGk4Jpi9C2XEMa2e4Ard4xxP0gLTx5CviYJRnRODO yqDaTmDc96dii76rVtTKmoH50IZERN6K1tL6rWsuG+6PG0+aioP2FHPmReqg90g6ntKR 4EjwLBfrbCuzDTzvo0HkfAwgGFAtOX6tvqE1FVseGDlw3bE3R96j02C7V39nsnGj9sIa t1Knl3SxNMU0GkB7GKATLIH5bUnRimjIccTkwkQRbNaGOGPzr6swbb/e7mWax39N3AeW p7PA== Return-Path: Date: Wed, 16 Jan 2019 22:51:00 -0000 From: Christian Brauner To: Zack Weinberg Cc: Florian Weimer , GNU C Library Subject: Re: Fwd: What can a signal handler do with SIGSTKSZ? Message-ID: <20190116225104.2thlwujlfd62ydsn@brauner.io> References: <874lafezhe.fsf@oldenburg2.str.redhat.com> <87sgxzdjl4.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-SW-Source: 2019-01/txt/msg00419.txt.bz2 On Fri, Jan 11, 2019 at 06:59:42PM -0500, Zack Weinberg wrote: > On Fri, Jan 11, 2019 at 3:29 PM Florian Weimer wrote: > > > > * Zack Weinberg: > > > by hook or by crook we _must_ find a way > > > to make it safe to call `_exit` and `abort`. > > > > abort delivers another signal, so that's going to be impossible to > > support with a really small stack, I think. > > see below > > > > Do you think we could push the kernel people to expose the space > > > requirement of a signal frame in some fashion that we could wrap up in > > > a new sysconf() constant? Then we could deprecate the constants, in > > > the same way that long ago PAGESIZE was replaced by > > > sysconf(_SC_PAGESIZE). > > > > That's an interesting idea. sigaltstack could also check that the size > > is at least that large, but then the question is how many sigaltstack > > users check the error return value. > > Probably not very many... > > > However, based on what I saw in the kernel sources, it's not that they > > have an exact upper bound in the sources or even at run time. I think > > the code simply uses space as it proceeds (at least on x86). But > > perhaps I misread it. > > Yeesh. I think that has got to get fixed, independent of everything else. > > This is not really my area of expertise, but here's what comes to mind > for a way forward: > > - Kernel-side signal delivery code is revamped so it knows an upper > bound (perhaps not an exact one) on the space requirement for a signal > frame, and exposes that to user space in a way that we can wrap up in > a sysconf() query. > - Kernel-side signal delivery code is revamped so that it knows how > much stack space is available (no matter where the stack came from -- > in the absence of other information I suppose it can use the bottom of > the memory mapping, but for sigaltstack it ought to use the specified > size) and, if there isn't enough space to write a complete signal > frame, it terminates the process as-if by the default action of > SIGSEGV instead of clobbering anything. > - We add glibc functions > > int alloc_sigstack(stack_t *ss, size_t scratch_needed); > void free_sigstack(stack_t *ss); > > alloc_sigstack allocates space for a signal stack, guaranteeing to > provide at least scratch_needed bytes of space for the signal > handler's local variables and any functions it calls, plus an > appropriate amount of overhead space for the signal frame. The total > allocation will be rounded up to a whole number of pages and will have > no-access guard pages on either side of it. It can fail. > free_sigstack, naturally, deallocates the stack again. > > The second change is what deals with people trying to call abort() > from inside a signal handler when there might not be enough space for > another signal frame. It also should solve the AVX2 lack-of-space > issue -- programs using the old constants may crash but they shouldn't > behave unpredictably. > > The point of alloc_sigstack and free_sigstack, over just telling > people to use the new sysconf query, is that they give you guard > pages, which will help with programs underestimating the amount of > space they need. > > Christian: I don't know if this stuff has been brought up on the > kernel lists before, but it probably does need to be. I'll bring it up soon(ish). There's a bunch of stuff that I have on my (kernel) plate that I need to prioritize before I can free up memory for that discussion. :) Christian