From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 0845F211B4 for ; Sat, 12 Jan 2019 00:00:01 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; q=dns; s=default; b=iR5Q WHg2uF2IPf8vo/5myQvjDlCyz211cV4EVybbt4x2XLeqQQWAVTEKbdSFgNy4hiPF 4fthEoyTJgwUl+9Ys0RSEd5XGEC+J5DZByl8Gq0wFKUhYQwYkErs1tzoG1rQycC/ 5Qtzw1YHYbn5fsLd7xjzYVyzesg2s397SCqfgsU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; s=default; bh=MX5wCuY6sv +iJcuQmmdHqXpQYl8=; b=uI0d7srH7N9l4woCABJTjhLRZCQLGbV9qtJzckSqGk seGaqLquylHnks/5uEMuNbtB5p8wir0Sc14itrrC052gJc4LQFLi1RK8JxfgozKB DiwRDQi2I2QdfFb/lTQY+77Hkx54ToSy1TvNoe9xOS9Cscce4AvHHrVWFkt9chmV 0= Received: (qmail 53041 invoked by alias); 11 Jan 2019 23:59:58 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 53030 invoked by uid 89); 11 Jan 2019 23:59:58 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mailbackend.panix.com MIME-Version: 1.0 References: <874lafezhe.fsf@oldenburg2.str.redhat.com> <87sgxzdjl4.fsf@oldenburg2.str.redhat.com> In-Reply-To: <87sgxzdjl4.fsf@oldenburg2.str.redhat.com> From: Zack Weinberg Date: Fri, 11 Jan 2019 18:59:42 -0500 Message-ID: Subject: Re: Fwd: What can a signal handler do with SIGSTKSZ? To: Florian Weimer , Christian Brauner Cc: GNU C Library Content-Type: text/plain; charset="UTF-8" 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. zw zw