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 641952C12D for ; Sat, 31 Aug 2024 18:34:08 +0200 (CEST) Received: (qmail 15551 invoked by uid 550); 31 Aug 2024 16:34:04 -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 15497 invoked from network); 31 Aug 2024 16:34:04 -0000 Date: Sat, 31 Aug 2024 12:33:55 -0400 From: Rich Felker To: alice Cc: musl@lists.openwall.com Message-ID: <20240831163354.GQ10433@brightrain.aerifal.cx> References: <20240829125727.GK10433@brightrain.aerifal.cx> <20240829190348.GL10433@brightrain.aerifal.cx> <20240829202337.GM10433@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240829202337.GM10433@brightrain.aerifal.cx> 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 04:23:38PM -0400, Rich Felker wrote: > 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. I'm working on the fix for this, but I think one decision needs to be made that I'd like input from ppc folks on: We can either change the definition of the MINSIGSTKSZ macro on powerpc64 (does 32-bit need change too??) or we can add a mechanism for the arch to define an alternate minimum for sysconf(_SC_MINSIGSTKSZ) that might be higher than MINSIGSTKSZ. The former is (probably very minor) "ABI breakage", but I don't think anything would care. Without further fiddling to detect old kernels, either fix *probably* breaks old ppc binaries which are using the MINSIGSTKSZ macro value, even if running on old kernels -- the dynamic sysconf(_SC_MINSIGSTKSZ) limit would always be at least 8k, and since they'd be passing stacks smaller than 8k, sigaltstack would need to fail. (It's not failing now, which is a bug; I'm fixing that because otherwise you'll be able to setup alt stacks that overflow and clobber memory, since the kernel doesn't correctly check the min.) Rich