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=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 [8.43.85.97]) (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 4C3F41F4B4 for ; Tue, 6 Oct 2020 09:25:45 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 916FF386191F; Tue, 6 Oct 2020 09:25:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 916FF386191F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1601976343; bh=9XsZ1E5KtxBcBLiPaDl93p0+L7npeDQQbZlZ5SAk1r0=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=ISnsAEb5dmXM8ym/UX0BlZmxEREVJqNNHu/xIa79GzHrrzFj9x5coj2fJg+nitW30 8iJ3FBtrWZk/m9HhnRYZEzeW/PyIxKgbbI2QS3b9N5Tv38zYPF/f/7xIbYs0ni2bCa cmuUMv3iSXWeVR+ZqN6E3JPgPWWTmpUKbg4RMBgQ= Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 1D68A3861854 for ; Tue, 6 Oct 2020 09:25:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1D68A3861854 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 A53D7113E; Tue, 6 Oct 2020 02:25: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 A89A23F71F; Tue, 6 Oct 2020 02:25:37 -0700 (PDT) Date: Tue, 6 Oct 2020 10:25:34 +0100 To: "H.J. Lu" Subject: Re: [RFC PATCH 0/4] x86: Improve Minimum Alternate Stack Size Message-ID: <20201006092532.GU6642@arm.com> References: <20200929205746.6763-1-chang.seok.bae@intel.com> <20201005134534.GT6642@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-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: Dave Martin via Libc-alpha Reply-To: Dave Martin Cc: linux-arch , Len Brown , Tony Luck , GNU C Library , "Ravi V. Shankar" , "Chang S. Bae" , the arch/x86 maintainers , LKML , Dave Hansen , Andy Lutomirski , Linux API , Thomas Gleixner , Borislav Petkov , Ingo Molnar Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On Mon, Oct 05, 2020 at 10:17:06PM +0100, H.J. Lu wrote: > On Mon, Oct 5, 2020 at 6:45 AM Dave Martin wrote: > > > > On Tue, Sep 29, 2020 at 01:57:42PM -0700, Chang S. Bae wrote: > > > During signal entry, the kernel pushes data onto the normal userspace > > > stack. On x86, the data pushed onto the user stack includes XSAVE state, > > > which has grown over time as new features and larger registers have been > > > added to the architecture. > > > > > > MINSIGSTKSZ is a constant provided in the kernel signal.h headers and > > > typically distributed in lib-dev(el) packages, e.g. [1]. Its value is > > > compiled into programs and is part of the user/kernel ABI. The MINSIGSTKSZ > > > constant indicates to userspace how much data the kernel expects to push on > > > the user stack, [2][3]. > > > > > > However, this constant is much too small and does not reflect recent > > > additions to the architecture. For instance, when AVX-512 states are in > > > use, the signal frame size can be 3.5KB while MINSIGSTKSZ remains 2KB. > > > > > > The bug report [4] explains this as an ABI issue. The small MINSIGSTKSZ can > > > cause user stack overflow when delivering a signal. > > > > > > In this series, we suggest a couple of things: > > > 1. Provide a variable minimum stack size to userspace, as a similar > > > approach to [5] > > > 2. Avoid using a too-small alternate stack > > > > I can't comment on the x86 specifics, but the approach followed in this > > series does seem consistent with the way arm64 populates > > AT_MINSIGSTKSZ. > > > > I need to dig up my glibc hacks for providing a sysconf interface to > > this... > > Here is my proposal for glibc: > > https://sourceware.org/pipermail/libc-alpha/2020-September/118098.html Thanks for the link. Are there patches yet? I already had some hacks in the works, but I can drop them if there's something already out there. > 1. Define SIGSTKSZ and MINSIGSTKSZ to 64KB. Can we do this? IIUC, this is an ABI break and carries the risk of buffer overruns. The reason for not simply increasing the kernel's MINSIGSTKSZ #define (apart from the fact that it is rarely used, due to glibc's shadowing definitions) was that userspace binaries will have baked in the old value of the constant and may be making assumptions about it. For example, the type (char [MINSIGSTKSZ]) changes if this #define changes. This could be a problem if an newly built library tries to memcpy() or dump such an object defined by and old binary. Bounds-checking and the stack sizes passed to things like sigaltstack() and makecontext() could similarly go wrong. > 2. Add _SC_RSVD_SIG_STACK_SIZE for signal stack size reserved by the kernel. How about "_SC_MINSIGSTKSZ"? This was my initial choice since only the discovery method is changing. The meaning of the value is exactly the same as before. If we are going to rename it though, it could make sense to go for something more directly descriptive, say, "_SC_SIGNAL_FRAME_SIZE". The trouble with including "STKSZ" is that is sounds like a recommendation for your stack size. While the signal frame size is relevant to picking a stack size, it's not the only thing to consider. Also, do we need a _SC_SIGSTKSZ constant, or should the entire concept of a "recommended stack size" be abandoned? glibc can at least make a slightly more informed guess about suitable stack sizes than the kernel (and glibc already has to guess anyway, in order to determine the default thread stack size). > 3. Deprecate SIGSTKSZ and MINSIGSTKSZ if _SC_RSVD_SIG_STACK_SIZE > is in use. Great if we can do it. I was concerned that this might be controversial. Would this just be a recommendation, or can we enforce it somehow? Cheers ---Dave