From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id C6CCE3857C45 for ; Wed, 7 Oct 2020 10:19:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C6CCE3857C45 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4407D11B3; Wed, 7 Oct 2020 03:19:39 -0700 (PDT) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 61C433F71F; Wed, 7 Oct 2020 03:19:37 -0700 (PDT) Date: Wed, 7 Oct 2020 11:19:34 +0100 From: Dave Martin To: Florian Weimer Cc: Dave Martin via Libc-alpha , Dave Hansen , linux-arch , Tony Luck , "Ravi V. Shankar" , Len Brown , "Chang S. Bae" , the arch/x86 maintainers , LKML , Andy Lutomirski , Linux API , Thomas Gleixner , Borislav Petkov , Ingo Molnar Subject: Re: [RFC PATCH 0/4] x86: Improve Minimum Alternate Stack Size Message-ID: <20201007101933.GF6642@arm.com> 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> <87362rp65v.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87362rp65v.fsf@oldenburg2.str.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Wed, 07 Oct 2020 10:19:41 -0000 On Tue, Oct 06, 2020 at 08:21:00PM +0200, Florian Weimer wrote: > * 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. If the architecture grows more or bigger registers, and if those registers are used in general-purpose code, then all stack frames will tend to grow, not just the signal frame. So a stack overflow might be caused by the larger signal frame by itself; or it might be caused by the growth of the stack of 20 function frames created by someone's signal handler. In the latter case, this is just a "normal" stack overflow, and nothing really to do with signals or SIGSTKSZ. Rebuilding with different compiler flags could also grow the stack usage and cause just the same problem. I also strongly suspect that people often don't think about signal nesting when allocating signal stacks. So, there might be a pre- existing potential overflow that just becomes more likely when the signal frame grows. That's not really SIGSTKSZ's fault. Of course, AVX-512 might never be used in general-purpose code. On AArch64, SVE can be used in general-purpose code, but it's too early to say what its prevalence will be in signal handlers. Probably low. > > 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). Ack, I think if SIGSTKSZ was too small significantly often, there would be more awareness of the issue. Cheers ---Dave