linux-kernel - Re: [RFC][possible bug] when should SS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 21 Mar 2020 10:59:41 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Stas Sergeev <stsp@...t.ru>, Ingo Molnar <mingo@...nel.org>,
        Linux API <linux-api@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][possible bug] when should SS_AUTODISARM have effect?

On Wed, Mar 18, 2020 at 7:16 PM Al Viro <viro@...iv.linux.org.uk> 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.