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] [day] [month] [year] [list]

Message-ID: <4b34bac5-9c1e-c1bb-c033-cd373efc1745@yandex.ru>
Date:   Sun, 22 Mar 2020 01:24:05 +0300
From:   stsp <stsp2@...dex.ru>
To:     Andy Lutomirski <luto@...nel.org>,
        Al Viro <viro@...iv.linux.org.uk>
Cc:     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?

21.03.2020 20:59, Andy Lutomirski пишет:
> 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.
> .

IMHO the signal delivery failure should
either call do_exit(), or be quite close to
sigreturn() failure, which is a SIGSEGV
with special si_code IIRC. If you ask me
(as probably the only user of SS_AUTODISARM,
special si_code and all that), I'd say that
I can live well without yet another notification
method. :) And you can always invent new
si_code rather than new signum, in case
the new method is really needed.