Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 06 Mar 2019 13:56:02 +0100
From: Florian Weimer <>
To: Rich Felker <>
Subject: Re: sigaltstack for implementation-internal signals?

* Rich Felker:

> If we add unblockable, implementation-internal signals that are
> flagged SA_ONSTACK, however, this breaks; now even if an application
> has taken the "proper precautions", they can be delivered in a state
> where the alt stack is nonempty but the stack pointer doesn't point
> into it, thereby causing it to get clobbered.

There's also the matter of applications which do not use signal handlers
at all (and thus never invoke sigaltstack) and have really small stacks,
or use the stack pointer register for something else.  Is either of that

I think it is not clear whether a libc implementation may generate
sporadic signals *at all* to support implementation needs.

Does musl use asynchronous implementation signals?  For glibc, we would
prefer synchronous delivery, that is, the handler runs before the
signal-generating system call returns.  This makes me wonder if we
should try to get the kernel to provide us a system call which allows us
to run code on a different thread, with signals disabled, but with the
caller's stack (from the original thread).  I think this would address
issues caused by strange stack pointer values in the target thread.

The Boehm-Demers-Weiser garbage collector would probably benefit from
that as well.


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.