Re: [RFC][possible bug] when should SS_AUTODISARM have effect?

[Andy Lutomirski]

On Wed, Mar 18, 2020 at 7:16 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>
>         Consider the following scenario:  SIGPIPE has SA_ONSTACK
> handler, SIGSEGV - non-SA_ONSTACK one.  SIGPIPE is delivered
> and we fail halfway through setting a sigframe for it.
> OK, we get SIGSEGV forced in, which gets handled not on altstack.
> But what should happen if we fail *after* having saved the
> altstack settings into the sigframe that got abandoned?
>
>         AFAICS, we get them reset and the original setting
> entirely lost.  Shouldn't that thing be applied only after
> we have succeeded in building the frame?  In signal_delivered(),
> perhaps...
>
>         I realize that this is out of scope for POSIX, so it's
> not a matter of standard compliance, but it looks like a bit
> of a QoI issue...

I suspect that the number of real programs that usefully handle
SIGSEGV due to signal delivery failure is extremely low.  And the
number of real programs that use SA_ONSTACK and expect to survive when
the alternate stack is bad may well be zero.

Honestly, if we actually want to make any of this useful, I think a
better design would be to use an entirely separate signal specifically
for signal delivery failure.  So we'd have SIGBADSIG, and signal
delivery failure tries to deliver SIGBADSIG.  The current design is
like if x86 handled exception failure by sending #PF.  The results
would be nonsensical.

But adding a feature like this would be silly unless someone actually
wanted to use it.