From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) by sourceware.org (Postfix) with ESMTPS id 5EA0138618F1 for ; Wed, 17 Mar 2021 10:44:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5EA0138618F1 Received: by mail-wr1-x42a.google.com with SMTP id x16so1300022wrn.4 for ; Wed, 17 Mar 2021 03:44:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=Bn90u44fy8L7FazXOSgNFKkR48EmU94fLQ8Y07NnDbg=; b=LnGOK66Gkb3RiJDzEPLa7bZcpMzTppMuWJfmXZiaGV8xJTdNUQoqRjsjplrMVZ1Lkc yFKoNK/QbKNX4JkhvsIE0uxNlJG8wMaOF8uwBNF2XZY0waEI1yTAgi66qYIzMJDLUopm pp5x/LCPIRZbMVyNvGR6a/V136IA39cmwWGNjDqetOELodWNlIm6WcHTU4y/8fES1CLw 37xA6kNGngsm4fTYlPvChQMF4sbAVQLAIWrtHjDlLMWLBR6znDv9cDWXfLsyDQ557ziA tWL1Rmo1Km7fjasXTdZ/heK1MVeVZ2E5KJB0S1kPKlGMsc/0RO+SLQbOzI4pJyT1AI2i RynA== X-Gm-Message-State: AOAM532H3e1WkGtgqoAccgD74mIiYpecqrx72KhXuemvpBh+ZtJcArpd fT00znWQP9J0MU85Neprybg= X-Google-Smtp-Source: ABdhPJzMIr4AJ4UN6QhUkf9RjJgTZhqswu3fbGhNtj+qV4sOmO3SCxJg6IEQ/jBzMi23oJWP+3NezQ== X-Received: by 2002:a05:6000:1acd:: with SMTP id i13mr1921557wry.48.1615977857523; Wed, 17 Mar 2021 03:44:17 -0700 (PDT) Received: from gmail.com (54033286.catv.pool.telekom.hu. [84.3.50.134]) by smtp.gmail.com with ESMTPSA id h13sm2026914wmq.29.2021.03.17.03.44.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Mar 2021 03:44:17 -0700 (PDT) Sender: Ingo Molnar Date: Wed, 17 Mar 2021 11:44:15 +0100 From: Ingo Molnar To: "Chang S. Bae" Cc: bp@suse.de, tglx@linutronix.de, luto@kernel.org, x86@kernel.org, len.brown@intel.com, dave.hansen@intel.com, hjl.tools@gmail.com, Dave.Martin@arm.com, jannh@google.com, mpe@ellerman.id.au, carlos@redhat.com, tony.luck@intel.com, ravi.v.shankar@intel.com, libc-alpha@sourceware.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v7 0/6] x86: Improve Minimum Alternate Stack Size Message-ID: <20210317104415.GA692070@gmail.com> References: <20210316065215.23768-1-chang.seok.bae@intel.com> <20210317100640.GC1724119@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210317100640.GC1724119@gmail.com> X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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, 17 Mar 2021 10:44:19 -0000 * Ingo Molnar wrote: > > * 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. > > > uapi: Define the aux vector AT_MINSIGSTKSZ > > x86/signal: Introduce helpers to get the maximum signal frame size > > x86/elf: Support a new ELF aux vector AT_MINSIGSTKSZ > > selftest/sigaltstack: Use the AT_MINSIGSTKSZ aux vector if available > > x86/signal: Detect and prevent an alternate signal stack overflow > > selftest/x86/signal: Include test cases for validating sigaltstack > > So this looks really complicated, is this justified? > > Why not just internally round up sigaltstack size if it's too small? > This would be more robust, as it would fix applications that use > MINSIGSTKSZ but don't use the new AT_MINSIGSTKSZ facility. > > I.e. does AT_MINSIGSTKSZ have any other uses than avoiding the > segfault if MINSIGSTKSZ is used to create a small signal stack? I.e. if the kernel sees a too small ->ss_size in sigaltstack() it would ignore ->ss_sp and mmap() a new sigaltstack instead and use that for the signal handler stack. This would automatically make MINSIGSTKSZ - and other too small sizes work today, and in the future. But the question is, is there user-space usage of sigaltstacks that relies on controlling or reading the contents of the stack? longjmp using programs perhaps? Thanks, Ingo