This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

zw

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]