Re: [musl] [PATCH] fix MINSIGSTKSZ and SIGSTKSZ for powerpc64

[Rich Felker <dalias@libc.org>]

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