From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: seccomp causes pthread_join() to hang
Date: Tue, 25 Jun 2019 19:26:17 -0400 [thread overview]
Message-ID: <20190625232617.GK1506@brightrain.aerifal.cx> (raw)
In-Reply-To: <7e5cec16-6b96-c585-98d4-86cacafbd84e@gmail.com>
On Wed, Jun 26, 2019 at 12:18:05AM +0100, Radostin Stoyanov wrote:
> Hello,
>
> In the test suite of CRIU [1] we have noticed an interesting bug
> which is caused by commit 8f11e6127fe93093f81a52b15bb1537edc3fc8af
> ("track all live threads in an AS-safe, fully-consistent linked
> list") [2].
>
> When seccomp is used in a multithreaded application it may cause
> pthread_join() to hang.
>
> This is a minimal application to reproduce the issue:
>
>
> #include <errno.h>
> #include <seccomp.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <pthread.h>
> #include <unistd.h>
>
> static void *fn()
> {
> scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_KILL);
> if (!ctx) {
> perror("seccomp_init");
> goto err;
> }
>
> if (seccomp_load(ctx) < 0) {
> perror("seccomp_load");
> goto err;
> }
>
> /* This should cause SIG_KILL */
> getpid();
> err:
> return (void *)1;
> }
>
> int main()
> {
> pthread_t t1;
>
> if (pthread_create(&t1, NULL, fn, NULL)) {
> perror("pthread_create");
> return -1;
> }
>
> if (pthread_join(t1, NULL)) {
> perror("pthread_join");
> return -1;
> }
>
> return 0;
> }
>
>
> Expected behaviour: Thread t1 should receive SIG_KILL and the main
> thread should return 0.
> Actual behaviour: pthread_join() hangs.
> Reproducibility: Always
> Regression: Yes
>
>
> This bug can be reproduced with Alpine 3.10 ($ docker run -it
> alpine:3.10 sh).
A fundamental property of the pthread API, and part of why threads are
a much better primitive than processes for lots of purposes, is that
threads are not killable; only whole processes are. Any configuration
that results in a thread being terminated out from under the process
has all sorts of extremely dangerous conditions with memory/locks
being left in inconsistent state, tid reuse while the application
thinks the old thread is still alive, etc., and fundamentally can't be
supported. What you're seeing is exposure of a serious existing
problem with this seccomp usage, not a regression.
Rich
next prev parent reply other threads:[~2019-06-25 23:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-25 23:18 Radostin Stoyanov
2019-06-25 23:26 ` Rich Felker [this message]
2019-06-26 7:30 ` Radostin Stoyanov
2019-06-26 11:25 ` Szabolcs Nagy
2019-06-26 13:43 ` Radostin Stoyanov
2019-06-26 15:33 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190625232617.GK1506@brightrain.aerifal.cx \
--to=dalias@aerifal.cx \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).