From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 177F52DC80 for ; Thu, 29 Aug 2024 22:54:51 +0200 (CEST) Received: (qmail 15610 invoked by uid 550); 29 Aug 2024 20:54:47 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 15569 invoked from network); 29 Aug 2024 20:54:46 -0000 Date: Thu, 29 Aug 2024 16:54:38 -0400 From: Rich Felker To: Linux Kernel Mailing List Cc: linux-api@vger.kernel.org, libc-alpha@sourceware.org, musl@lists.openwall.com Message-ID: <20240829205436.GA14562@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.5 (2018-04-13) Subject: [musl] AT_MINSIGSTKSZ mismatched interpretation kernel vs libc As I understand it, the AT_MINSIGSTKSZ auxv value is supposed to be a suitable runtime value for MINSIGSTKSZ (sysconf(_SC_MINSIGSTKSZ)), such that it's safe to pass as a size to sigaltstack. However, this is not how the kernel actually implements it. At least on x86 and powerpc, the kernel fills it via get_sigframe_size, which computes the size of the sigcontext/siginfo/etc to be pushed and uses that directly, without allowing any space for actual execution, and without ensuring the value is at least as large as the legacy constant MINSIGSTKSZ. This leads to two problems: 1. If userspace uses the value without clamping it not-below MINSIGSTKSZ, sigaltstack will fail with ENOMEM. 2. If the kernel needs more space than MINSIGSTKSZ just for the signal frame structures, userspace that trusts AT_MINSIGSTKSZ will only allocate enough for the frame, and the program will immediately crash/stack-overflow once execution passes to userspace. Since existing kernels in the wild can't be fixed, and since it looks like the problem is just that the kernel chose a poor definition of AT_MINSIGSTKSZ, I think userspace (glibc, musl, etc.) need to work around the problem, adding a per-arch correction term to AT_MINSIGSTKSZ that's basically equal to: legacy_MINSIGSTKSZ - AT_MINSIGSTKSZ as returned on legacy hw such that adding the correction term would reproduce the expected value MINSIGSTKSZ. The only question is whether the kernel will commit to keeping this behavior, or whether it would be "fixed" to include all the needed working space when they eventually decide they want bigger stacks for some new register file bloat. I think keeping the current behavior, so we can just add a fixed offset, is probably the best thing to do. Rich