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=-4.0 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 221A0211B4 for ; Mon, 14 Jan 2019 16:23:03 +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:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=O0ohqlrLQaHJZIjf sXbj/pjQGBYSTMcY0/hP0aYiVxwW53si4mEL6qDJwhnZqyZ7mI+p6vV/m553puxL phKS8uWxiOWVQGAWdAkvwtXFn2gTSd2mEHcwp6N5JdrMyPMym7SKrOvHilDwqP49 gpiNME6lCiYqBDU6Zr0JUG3EZvU= 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:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=p0FIRfkP2V9Qia1vNjsl69 w3ndo=; b=sUT5i4CRs+VAPufI23e9iO6XO3/6poIMiB3rhwbmmSSdJGi+m/2ZGG Ukm0tpaLkKQmH8qFGPqPcA6Xpzii7vAtigmomjFRddDW/GU1bERYpspSatVMromN jpnZLlMbnSlbRzSvuHaRVHLkwYls3/eqeljW/Rn2LIacsRzXKOSes= Received: (qmail 47185 invoked by alias); 14 Jan 2019 16:23:00 -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 47074 invoked by uid 89); 14 Jan 2019 16:23:00 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-qt1-f174.google.com Subject: Re: Fwd: What can a signal handler do with SIGSTKSZ? To: Florian Weimer , Szabolcs Nagy Cc: Zack Weinberg , Christian Brauner , nd , GNU C Library References: <874lafezhe.fsf@oldenburg2.str.redhat.com> <87sgxzdjl4.fsf@oldenburg2.str.redhat.com> <61925098-4669-b478-9baf-644818d26a44@arm.com> <87d0ozb4c8.fsf@oldenburg2.str.redhat.com> From: Carlos O'Donell Openpgp: preference=signencrypt Message-ID: <0a995c61-62d6-7b09-8b5d-1d77b33a242d@redhat.com> Date: Mon, 14 Jan 2019 11:22:53 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <87d0ozb4c8.fsf@oldenburg2.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 1/14/19 11:18 AM, Florian Weimer wrote: > * Szabolcs Nagy: > >> i think proposing sysconf(_SC_{MIN}SIGSTKSZ) for posix is the >> right solution with the kernel providing an upper bound of the >> stack frame in AT_MINSIGSTKSZ (as it already does on aarch64). > > It's still a bit nasty for process migration, but at least it should for > VM migration. I think that would be a reasonable compromise. > > Of course, we'd still need a way to determine how much we should add on > top of AT_MINSIGSTKSZ for the application developer's benefit. 8-) The value of SIGSTKSZ seems to be a "culturally relevant detail" that will probably be impossible to pin down to a real value. If *I* were a developer I might expect as Zach pointed out, that I can call every function on the list of callable AS-safe functions, at least once, without recursion, and expect them to operate correctly. A test case for this would therefore be a main, that register a handler that exercises *all* functions in the AS-safe list, and then looks for stack corruption at each execution. The test could also be used to set the value to some accepted value for all machines. Can we do this in practice? -- Cheers, Carlos.