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;
Date:   Wed, 30 Jun 2021 15:02:19 +1000
From:   Aleksa Sarai <cyphar@cyphar.com>
To:     "Eric W. Biederman" <ebiederm@xmission.com>
Cc:     linux-api@vger.kernel.org, Kees Cook <keescook@chromium.org>,
        Andy Lutomirski <luto@amacapital.net>,
        Will Drewry <wad@chromium.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Al Viro <viro@ZenIV.linux.org.uk>,
        Michael Kerrisk <mtk.manpages@gmail.com>,
        linux-man@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Semantics of SECCOMP_MODE_STRICT?
Message-ID: <20210630050219.nwixaloqs5oq5juy@senku>
References: <87r1gkp9i7.fsf@disp2133>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="knyuqndtsekusods"
Content-Disposition: inline
In-Reply-To: <87r1gkp9i7.fsf@disp2133>
Precedence: bulk


--knyuqndtsekusods
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2021-06-29, Eric W. Biederman <ebiederm@xmission.com> wrote:
>=20
> I am the process of cleaning up the process exit path in the kernel, and
> as part of that I am looking at the callers of do_exit.  A very
> interesting one is __seccure_computing_strict.
>=20
> Looking at the code is very clear that if a system call is attempted
> that is not in the table the thread attempting to execute that system
> call is terminated.
>=20
> Reading the man page for seccomp it says that the process is delivered
> SIGKILL.
>=20
> The practical difference is what happens for multi-threaded
> applications.
>=20
> What are the desired semantics for a multi-threaded application if one
> thread attempts to use a unsupported system call?  Should the thread be
> terminated or the entire application?
>=20
> Do we need to fix the kernel, or do we need to fix the manpages?

My expectation is that the correct action should be the equivalent of
SECCOMP_RET_KILL(_THREAD) which kills the thread and is the current
behaviour (SECCOMP_RET_KILL_PROCESS is relatively speaking quite new).

--=20
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

--knyuqndtsekusods
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQSxZm6dtfE8gxLLfYqdlLljIbnQEgUCYNv62AAKCRCdlLljIbnQ
EmqeAQCwE2RYKejytscSCZFsA8BmtrqPevAElfKrXqcDdvKRoQEAqAhoskdp6IIK
QTCUu1vbkKCwS4S63ntMofnCIFFKggE=
=5aqA
-----END PGP SIGNATURE-----

--knyuqndtsekusods--