Does anyone need executable stack?

[Korona]

Back to the topic about stacks. I'm not getting why would one want to inject code into stack for returns from signal handler. Can not that be handled by having a bit of prologue and epilogue code in libc / glue library? Instead of registering the address of signal handler directly with kernel, store the signal handler callback in userspace variable and register the beginning of the prologue code instead.

Yes, that can indeed be done and it's the VDSO code that nullplan was referring to (and on Linux, sigaction() has a SA_RESTORER flag for this purpose). The stack-based solution is done by Linux for uncooperative libcs (which were presumably used at some point in the past).

[nullplan]

The stack-based solution is done by Linux for uncooperative libcs (which were presumably used at some point in the past).

Was done. Nowadays the code exists only to mark the stack frame (apparently, GDB depends on it). The old trampoline is older than the VDSO, which is what is now used for uncooperative libcs. Indeed, not using SA_RESTORER could be beneficial, as the VDSO trampolines also get the exception handler frame attached to it that contains all the data on how to restore the higher frames.

[Korona]

You can also add the exception handling annotations to your libc (via CFI pseudo instructions). We do that to get stack traces across exception stacks in the kernel.