[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAA+XzTPd55UgrWkp9weqerhLaxuYEZzO9hc9SVN2CxepiYTwkA@mail.gmail.com>
Date: Wed, 29 Jul 2026 12:06:02 -0700
From: Nat Mote <nat@...grep.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: SIGSTKSZ is insufficiently-large on some platforms
Thanks for the response. I hadn't seen the past discussion. What you
propose is the shape of the workaround I'm applying and I am glad to hear
that a general solution is under discussion.
Nat
On Wed, Jul 29, 2026 at 11:47 AM Rich Felker <dalias@...c.org> wrote:
> 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
>
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.
