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-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 375351F4B4 for ; Tue, 6 Oct 2020 18:21:16 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4CE7F3959E72; Tue, 6 Oct 2020 18:21:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4CE7F3959E72 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1602008474; bh=vLEPMopDgwBeHhoD6xTsXdWXnyecjzlObkKeapKxZb8=; h=To:Subject:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=tKtUGqgGfoxs4ywS6S6E+z9g26P84d04xmYU+090XLEiQ+oftwh6Qo7E39P5BCODN COE+IvOrVzbC675a2/+cVe8PmDJiC1IHtnOPCmrkEgipOXNdbfILOcn6xi4NFLGqjC lEJhRGVYfx6ECx46pi0SBfcXDPYRBvIMMcnGx9gI= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 87B903857C54 for ; Tue, 6 Oct 2020 18:21:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 87B903857C54 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-461-alcayjT3P7G1iHsDj3bAkg-1; Tue, 06 Oct 2020 14:21:08 -0400 X-MC-Unique: alcayjT3P7G1iHsDj3bAkg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 777FF64088; Tue, 6 Oct 2020 18:21:05 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-113-154.ams2.redhat.com [10.36.113.154]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E2F4F60BFA; Tue, 6 Oct 2020 18:21:01 +0000 (UTC) To: Dave Martin via Libc-alpha Subject: Re: [RFC PATCH 0/4] x86: Improve Minimum Alternate Stack Size References: <20200929205746.6763-1-chang.seok.bae@intel.com> <20201005134534.GT6642@arm.com> <20201006092532.GU6642@arm.com> <20201006152553.GY6642@arm.com> <7663eff0-6c94-f6bf-f3e2-93ede50e75ed@intel.com> <20201006170020.GB6642@arm.com> Date: Tue, 06 Oct 2020 20:21:00 +0200 In-Reply-To: <20201006170020.GB6642@arm.com> (Dave Martin via Libc-alpha's message of "Tue, 6 Oct 2020 18:00:21 +0100") Message-ID: <87362rp65v.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Florian Weimer via Libc-alpha Reply-To: Florian Weimer Cc: linux-arch , Len Brown , Tony Luck , "Ravi V. Shankar" , Linux API , "Chang S. Bae" , the arch/x86 maintainers , LKML , Ingo Molnar , Dave Hansen , Andy Lutomirski , Thomas Gleixner , Borislav Petkov , Dave Martin Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" * Dave Martin via Libc-alpha: > On Tue, Oct 06, 2020 at 08:33:47AM -0700, Dave Hansen wrote: >> On 10/6/20 8:25 AM, Dave Martin wrote: >> > Or are people reporting real stack overruns on x86 today? >> >> We have real overruns. We have ~2800 bytes of XSAVE (regisiter) state >> mostly from AVX-512, and a 2048 byte MINSIGSTKSZ. > > Right. Out of interest, do you believe that's a direct consequence of > the larger kernel-generated signal frame, or does the expansion of > userspace stack frames play a role too? I must say that I do not quite understand this question. 32 64-*byte* registers simply need 2048 bytes of storage space worst case, there is really no way around that. > In practice software just assumes SIGSTKSZ and then ignores the problem > until / unless an actual stack overflow is seen. > > There's probably a lot of software out there whose stack is > theoretically too small even without AVX-512 etc. in the mix, especially > when considering the possibility of nested signals... That is certainly true. We have seen problems with ntpd, which requested a 16 KiB stack, at a time when there were various deductions from the stack size, and since the glibc dynamic loader also uses XSAVE, ntpd exceeded the remaining stack space. But in this case, we just fudged the stack size computation in pthread_create and made it less likely that the dynamic loader was activated, which largely worked around this particular problem. For MINSIGSTKSZ, we just don't have this option because it's simply too small in the first place. I don't immediately recall a bug due to SIGSTKSZ being too small. The test cases I wrote for this were all artificial, to raise awareness of this issue (applications treating these as recommended values, rather than minimum value to avoid immediately sigaltstack/phtread_create failures, same issue with PTHREAD_STACK_MIN). Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill