Re: Fwd: What can a signal handler do with SIGSTKSZ?

[Christian Brauner <christian at brauner dot io>]

On Fri, Jan 11, 2019 at 06:59:42PM -0500, Zack Weinberg wrote:
> On Fri, Jan 11, 2019 at 3:29 PM Florian Weimer <fweimer@redhat.com> wrote:
> >
> > * Zack Weinberg:
> > > by hook or by crook we _must_ find a way
> > > to make it safe to call `_exit` and `abort`.
> >
> > abort delivers another signal, so that's going to be impossible to
> > support with a really small stack, I think.
> 
> see below
> 
> > > Do you think we could push the kernel people to expose the space
> > > requirement of a signal frame in some fashion that we could wrap up in
> > > a new sysconf() constant?  Then we could deprecate the constants, in
> > > the same way that long ago PAGESIZE was replaced by
> > > sysconf(_SC_PAGESIZE).
> >
> > That's an interesting idea.  sigaltstack could also check that the size
> > is at least that large, but then the question is how many sigaltstack
> > users check the error return value.
> 
> Probably not very many...
> 
> > However, based on what I saw in the kernel sources, it's not that they
> > have an exact upper bound in the sources or even at run time.  I think
> > the code simply uses space as it proceeds (at least on x86).  But
> > perhaps I misread it.
> 
> Yeesh.  I think that has got to get fixed, independent of everything else.
> 
> This is not really my area of expertise, but here's what comes to mind
> for a way forward:
> 
>  - Kernel-side signal delivery code is revamped so it knows an upper
> bound (perhaps not an exact one) on the space requirement for a signal
> frame, and exposes that to user space in a way that we can wrap up in
> a sysconf() query.
>  - Kernel-side signal delivery code is revamped so that it knows how
> much stack space is available (no matter where the stack came from --
> in the absence of other information I suppose it can use the bottom of
> the memory mapping, but for sigaltstack it ought to use the specified
> size) and, if there isn't enough space to write a complete signal
> frame, it terminates the process as-if by the default action of
> SIGSEGV instead of clobbering anything.
>  - We add glibc functions
> 
>     int alloc_sigstack(stack_t *ss, size_t scratch_needed);
>     void free_sigstack(stack_t *ss);
> 
> alloc_sigstack allocates space for a signal stack, guaranteeing to
> provide at least scratch_needed bytes of space for the signal
> handler's local variables and any functions it calls, plus an
> appropriate amount of overhead space for the signal frame.  The total
> allocation will be rounded up to a whole number of pages and will have
> no-access guard pages on either side of it.  It can fail.
> free_sigstack, naturally, deallocates the stack again.
> 
> The second change is what deals with people trying to call abort()
> from inside a signal handler when there might not be enough space for
> another signal frame.  It also should solve the AVX2 lack-of-space
> issue -- programs using the old constants may crash but they shouldn't
> behave unpredictably.
> 
> The point of alloc_sigstack and free_sigstack, over just telling
> people to use the new sysconf query, is that they give you guard
> pages, which will help with programs underestimating the amount of
> space they need.
> 
> Christian: I don't know if this stuff has been brought up on the
> kernel lists before, but it probably does need to be.

I'll bring it up soon(ish). There's a bunch of stuff that I have on my
(kernel) plate that I need to prioritize before I can free up memory for
that discussion. :)

Christian