[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA+XzTNmvhbhjXb=g5i68_rbefp2OGPPYJU21kcaMXefHAx=1A@mail.gmail.com>
Date: Wed, 29 Jul 2026 11:33:03 -0700
From: Nat Mote <nat@...grep.com>
To: musl@...ts.openwall.com
Subject: SIGSTKSZ is insufficiently-large on some platforms
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.
Content of type "text/html" skipped
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.
