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 33DF92D9F4 for ; Thu, 29 Aug 2024 22:23:52 +0200 (CEST) Received: (qmail 5730 invoked by uid 550); 29 Aug 2024 20:23: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 5686 invoked from network); 29 Aug 2024 20:23:47 -0000 Date: Thu, 29 Aug 2024 16:23:38 -0400 From: Rich Felker To: alice Cc: musl@lists.openwall.com Message-ID: <20240829202337.GM10433@brightrain.aerifal.cx> References: <20240829125727.GK10433@brightrain.aerifal.cx> <20240829190348.GL10433@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH] fix MINSIGSTKSZ and SIGSTKSZ for powerpc64 On Thu, Aug 29, 2024 at 09:11:38PM +0200, alice wrote: > On Thu Aug 29, 2024 at 9:03 PM CEST, Rich Felker wrote: > > On Thu, Aug 29, 2024 at 06:00:52PM +0200, alice wrote: > > > On Thu Aug 29, 2024 at 2:57 PM CEST, Rich Felker wrote: > > > > On Thu, Aug 29, 2024 at 05:38:42AM +0200, psykose wrote: > > > > > since kernel commit 2f82ec19757f58549467db568c56e7dfff8af283 > > > > > (https://github.com/torvalds/linux/commit/2f82ec19757f58549467db568c56e7dfff8af283) > > > > > the kernel has updated these minimum values. having these small values breaks > > > > > sysconf(_SC_MINSIGSTKSZ) too; it returns 4224 in musl currently which ends up > > > > > returning ENOMEM from the syscall made in sigaltstack. > > > > > > > > > > raising these to match the kernel fixes sigaltstack use on powerpc64(le). > > > > > caught by glib's 2.82 testsuite > > > > > > > > I don't follow how you're claiming sysconf(_SC_MINSIGSTKSZ) is broken.. > > > > It will just return the kernel-provided value on new kernels that > > > > insist on having a larger stack. In particular I don't see where the > > > > value 4224 is supposed to be coming from. If there's something I'm > > > > missing, please explain. > > > > > > sysconf(_SC_MINSIGSTKSZ) returns 4224 on ppc64le (this is as far as i know > > > expected). > > > > I don't have a real system handy to test on, so I'm executing this > > mentally, and not seeing where 4224 comes from. > > sysconf(_SC_MINSIGSTKSZ) should return the kernel-provided value from > > __getauxval(AT_MINSIGSTKSZ) unless it's less than the fixed macro > > value MINSIGSTKSZ. Since that's 4096, the only way I can see this > > happening is if the kernel filled in AT_MINSIGSTKSZ as 4224, which > > would be a kernel bug...? > > yes, that getauxval gives 4224. > feel free to forward it to the right place if you think it's a kernel bug :) > > (it might just be an oversight since it was coordinated with glibc and so no > programs ever hit this as glibc made the minimum match the 8192 correctly..) Wow, it is a kernel bug: https://elixir.bootlin.com/linux/v6.10.6/source/arch/powerpc/kernel/signal_64.c#L69 So I guess we need a workaround for this. It will prevent the functionality from working at all, making it so programs always crash if the kernel needs more than the "default" 8k, because it has no actual working stack space included, only the size of the signal frame. Fixing this will require coordination with the kernel folks to figure out if they intend to leave it broken (i.e. if we need to add 3968 on top of what they tell us via the aux vector) or if they're going to make a contract that, if the value is >8192, it's the full correct value for min signal stack size, not just the sigframe. BTW this is why I like insisting on actually understanding the source of a problem rather than just making changes to make it go away. Here we discovered a much deeper issue that's going to bite folks in the future. Rich