Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   ebiederm@xmission.com (Eric W. Biederman)
To:     Kees Cook <keescook@chromium.org>
Cc:     linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Oleg Nesterov <oleg@redhat.com>,
        Al Viro <viro@zeniv.linux.org.uk>
References: <87y26nmwkb.fsf@disp2133>
        <20211020174406.17889-13-ebiederm@xmission.com>
        <202110210923.F5BE43C@keescook>
Date:   Thu, 21 Oct 2021 11:33:43 -0500
In-Reply-To: <202110210923.F5BE43C@keescook> (Kees Cook's message of "Thu, 21
        Oct 2021 09:24:22 -0700")
Message-ID: <87ilxqbamw.fsf@disp2133>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [PATCH 13/20] signal: Implement force_fatal_sig
Precedence: bulk

Kees Cook <keescook@chromium.org> writes:

> On Wed, Oct 20, 2021 at 12:43:59PM -0500, Eric W. Biederman wrote:
>> This is interesting both because it makes force_sigsegv simpler and
>> because there are a couple of buggy places in the kernel that call
>> do_exit(SIGILL) or do_exit(SIGSYS) because there is no straight
>> forward way today for those places to simply force the exit of a
>> process with the chosen signal.  Creating force_fatal_sig allows
>> those places to be implemented with normal signal exits.
>
> I assume this is talking about seccomp()? :) Should a patch be included
> in this series to change those?

Actually it is not talking about seccomp.  As far as I can tell seccomp
is deliberately only killing a single thread when it calls do_exit.

I am thinking about places where we really want the entire process to
die and not just a single thread.  Please see the following changes
where I actually use force_fatal_sig.

Eric