linux-kernel - Re: [PATCH 13/20] signal: Implement force_fatal

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]

Message-ID: <87tuh1m7m0.fsf@disp2133>
Date:   Thu, 28 Oct 2021 11:33:59 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Oleg Nesterov <oleg@...hat.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH 13/20] signal: Implement force_fatal_sig

Linus Torvalds <torvalds@...ux-foundation.org> writes:

> On Mon, Oct 25, 2021 at 9:58 PM Eric W. Biederman <ebiederm@...ssion.com> wrote:
>>
>> Rereading this I think you might be misreading something.
>
> Gaah. Yes, indeed.
>
>> force_siginfo_to_task takes a sigdfl parameter which I am setting in
>> force_fatal_signal.
>
> .. and I realized that the first time I read through it, but then when
> I read through it due to Andy saying it worries him, I missed it and
> thought the handler didn't get reset.
>
> So the patch is fine.

Thank you.

Andy is right that there is a race with sigaction changing the signal
handler.

To make complete_signal reliably recognize fatal signals is going to
take a bit of work.  None of it particularly hard but there are a lot of
pieces that need to be changed carefully.  Part of the problem is that
recognizing fatal signals early started out as an optimization, and
there remain places in complete_signal and prepare_signal that assume it
is always possible to not recognize fatal signals early and let
get_signal handle things.

The coredump handling of it is the biggest challenge.  Computing a
destination thread with wants_signal in complete_signal before dealing
with fatal signals (which don't care) means that wants_signal can
cause the early recognition of fatal signals to fail.

The entire blocked vs real_blocked set of signal masks are interesting.
The current way those signal masks work does not appear to allow knowing
when blocked is being overridden and blocked is stored in real_blocked.
Something I think needs to be known if fatal signal are always going to
be recognized early.

Given that race it looks like it is important to make the guarantee that
fatal signals are always recognized early.  So the rest of the kernel
can count on that property.

But I aim to get this set of changes into linux-next first.  As I don't
anything will melt down if we leave that race for a bit longer.

Eric