From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14261 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: seccomp causes pthread_join() to hang Date: Tue, 25 Jun 2019 19:26:17 -0400 Message-ID: <20190625232617.GK1506@brightrain.aerifal.cx> References: <7e5cec16-6b96-c585-98d4-86cacafbd84e@gmail.com> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="162658"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14277-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jun 26 01:26:32 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hfupb-000gE6-VS for gllmg-musl@m.gmane.org; Wed, 26 Jun 2019 01:26:32 +0200 Original-Received: (qmail 3375 invoked by uid 550); 25 Jun 2019 23:26:30 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 3343 invoked from network); 25 Jun 2019 23:26:29 -0000 Content-Disposition: inline In-Reply-To: <7e5cec16-6b96-c585-98d4-86cacafbd84e@gmail.com> Xref: news.gmane.org gmane.linux.lib.musl.general:14261 Archived-At: 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 > #include > #include > #include > #include > #include > #include > > 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