Re: [PATCH] Fix the use of sigaltstack to return to the saved main stack.

[Rich Felker <dalias@libc.org>]

On Wed, Jul 10, 2019 at 02:04:18PM -0400, James Y Knight wrote:
> On Tue, Jul 9, 2019 at 3:30 PM Rich Felker <dalias@libc.org> wrote:
> 
> > On Tue, Jul 09, 2019 at 03:01:50PM -0400, James Y Knight wrote:
> > > Previously, musl would reject the call, because the main stack has
> > > ss_size == 0 and ss_flags == SS_DISABLE.
> > >
> > > We could condition on ss_flags not containing SS_DISABLE, but instead,
> > > simply remove the ss_size check, as the kernel performs the same check,
> > > anyhow.
> >
> > Are you sure the kernel does? I'm pretty sure the reason the code is
> > here is that the kernel either does not check it, or does not perform
> > the check correctly in some special case. Sadly the commit messages in
> > musl were not as good back at the time when the code was written.
> >
> 
> As far back as the first git version (2.6.12-rc2), the kernel checks this
> condition. I haven't looked back any further...
> 
> However, I note now that musl uses different values for MINSIGSTKSIZE than
> the kernel does, on some architectures.
> 
> The usual value in the kernel is 2048. Only a few architectures set a
> differing value:
> alpha:4096
> arm64:5120
> ia64:131027
> sparc:4096
> 
> Musl usually uses 2048 as well, but sets other values on these
> architectures:
> arm64:6144
> powerpc:4096
> powerpc64:4096
> s390x:4096
> 
> (Musl doesn't support alpha, ia64, or sparc, so it's not using a lower
> value than the kernel anywhere, at least).
> 
> If it's important that stacks smaller than musl's MINSIGSTKSIZE be
> rejected, despite them being large enough for the kernel, then I suppose
> the check should be retained. Let me know -- I'll make a new patch
> implementing your suggestion if you still think that's the way to go.

It is important. It's both a normative requirement of POSIX, and a
matter of the smaller sizes accepted by the kernel being unsafe --
they don't actually fit a signal context due to the arch's register
file being huge, or having a reservation that it might be huge in the
future.

Rich