[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87tvggb1r1.fsf@oldenburg2.str.redhat.com>
Date: Wed, 06 Mar 2019 13:56:02 +0100
From: Florian Weimer <fweimer@...hat.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
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
supported?
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.
Thanks,
Florian
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.
