[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260729184548.GI27423@brightrain.aerifal.cx>
Date: Wed, 29 Jul 2026 14:45:49 -0400
From: Rich Felker <dalias@...c.org>
To: Nat Mote <nat@...grep.com>
Cc: musl@...ts.openwall.com
Subject: Re: SIGSTKSZ is insufficiently-large on some platforms
On Wed, Jul 29, 2026 at 11:33:03AM -0700, Nat Mote wrote:
> Musl 1.2.6 began enforcing
> <https://git.musl-libc.org/cgit/musl/commit/?id=300a1f53907a4acaadd9a696d0c67eee6fc10430>
> the minimum size of the signal stack based on the result of
> sysconf(_SC_MINSIGSTKSZ) which is determined at runtime in part based on
> specific details of the CPU. In contrast, SIGSTKSZ and MINSIGSTKSZ are
> constants, set based on the CPU architecture alone. For example, on x86_64
> <https://git.musl-libc.org/cgit/musl/tree/arch/x86_64/bits/signal.h?h=v1.2.6&id=9fa28ece75d8a2191de7c5bb53bed224c5947417#n6>,
> SIGSTKSZ is 8192.
>
> On an Intel(R) Xeon(R) Platinum 8488C CPU running Alpine 3.24, which ships
> with musl 1.2.6, I have observed sysconf(_SC_MINSIGSTKSZ) returning 12976.
> This means that any code calling sigaltstack with ss_size set to SIGSTKSZ
> will fail to allocate an alternative signal stack on such a platform. This
> seems to subvert the very purpose of SIGSTKSZ. It does not appear to have
> any use if one cannot rely on it to be a valid value for ss_size.
>
> I am preparing a workaround for the OCaml runtime
> <https://github.com/ocaml/ocaml/pull/14933>, which currently crashes
> immediately on startup on the platform described above. However, I suspect
> that other programs may also fall prey to this problem. I believe that a
> general fix in musl would be worthwhile. Perhaps SIGSTKSZ should be a macro
> that calls sysconf (which I believe is how glibc solves the problem). Maybe
> there is a better solution. Either way, it seems to me that SIGSTKSZ should
> always be a valid value for ss_size.
I'm not sure if you've followed the past discussion on this (there was
a lot on the list), but it's a mess, stemming from kernel folks
violating ABI stability ([MIN]SIGSTKSZ is ABI) by extending the
supported register file size.
At this point, the right solution is almost surely amending POSIX to
make the fixed constants optional, so that applications are forced to
use the variable sysconf() values. Until we get consensus on that or
some other sort of fix, what's needed is for applications to use
_SC_[MIN]SIGSTKSZ if the macro is defined, and use the value returned
by sysconf instead of the fixed [MIN]SIGSTKSZ constant if available.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
