From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14267 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Radostin Stoyanov Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: seccomp causes pthread_join() to hang Date: Wed, 26 Jun 2019 08:30:34 +0100 Message-ID: <28623527-b159-c1a8-01f2-394049f13836@gmail.com> References: <7e5cec16-6b96-c585-98d4-86cacafbd84e@gmail.com> <20190625232617.GK1506@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="225374"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 Cc: "Andrei Vagin (C)" , gorcunov@gmail.com To: musl@lists.openwall.com, Rich Felker Original-X-From: musl-return-14283-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jun 26 09:30:54 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 1hg2OK-000wTF-84 for gllmg-musl@m.gmane.org; Wed, 26 Jun 2019 09:30:52 +0200 Original-Received: (qmail 32721 invoked by uid 550); 26 Jun 2019 07:30:48 -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 32701 invoked from network); 26 Jun 2019 07:30:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=LDEnah3KmZ5C7k390iEdzmjApYhPuueq8LFP/w1KyNE=; b=VvV7dGmHknexN5ogOM6IL6PrgRnZ8r+RAhYWk2tKVY9D1d3wjyxfT88Zxsofsqk0Ej lclyEf9BSd6cEWbMixilmWDtfZldvpKCsIzWBe/v+5ul5oyC+YqBRzAGgdkwu1Kkd1W8 8Y4SNgQgnOCImVTShgw9wqiMq6J4oMBiQZ1AIc5lT5H4VA6ks3BT/kS/QjqsaoDBmQAb q1cWhs7DOn2tiJm94NSGomOh98WUwvv0RyJESYrDu6XOpqREnQkQOvdkkwj56cwPKcyV ZsRWRbPuT5ahm0q5o/XkLU7mc1mkUor0GDD/1PfwWLtvbA4lvPkQKMZBwWJvmuxlHdWU onUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=LDEnah3KmZ5C7k390iEdzmjApYhPuueq8LFP/w1KyNE=; b=IdIbfYWEMpkb5LfLkOxEm61udoeeXosEgBqTw0AB6Qd9LLrmdWNLX1iFv6VZpus8+m EIlB80wMyABkXUhIHc/Z6Q671yj2wijogA+t8ummh/BmDlmRW+jjH7pCT7+r7derpbXi XSEpSKIYEexIN8F6wnp57t0GhaSzqCa6pKK9oTRu2kaERAooQJ736qu1uRS7keH18TqK muWTSIYeBLbXuL9zdlR0w4oHaIiquG/WQlprk0TFXMzD0VqxpxAKs7qcS58Be3kez2WL kqD9eS0r24jF7AWzQQvrF0K33wAdwub+RjXoj2ixYsGuj6F3KX9GHWLHdTPRHN+rj0b7 r34w== X-Gm-Message-State: APjAAAWR5NyMTxzUyokia4PV7Uw0j/oKaFizM+0sOpvtyGAC7urMKT9h KKs6eUlr/K2tbQtNCseqPo8= X-Google-Smtp-Source: APXvYqyj7UQ9gTGP1uLsoHdu2MAymBo68p531xLdvSfk6ExNh6V3SRBeFQJagHb/DsEfuAWWjF6i6Q== X-Received: by 2002:a7b:cc09:: with SMTP id f9mr1629649wmh.68.1561534236701; Wed, 26 Jun 2019 00:30:36 -0700 (PDT) In-Reply-To: <20190625232617.GK1506@brightrain.aerifal.cx> Content-Language: en-GB Xref: news.gmane.org gmane.linux.lib.musl.general:14267 Archived-At: On 26/06/2019 00:26, Rich Felker wrote: > 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. From the man page of seccomp(2):     SECCOMP_RET_KILL_PROCESS: This value results in immediate termination of the process, with a core dump. ...     SECCOMP_RET_KILL_THREAD (or SECCOMP_RET_KILL): This  value results in immediate termination of the thread that made the system call. The system call is not executed. Other threads in the same thread group will continue to execute. ... > 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. I wrote "Regression: Yes" because this bug was recently introduced and it does not occur in previous versions. IMHO causing pthread_join() to hang when a thread has been terminated is not expected behaviour, at least because the man page for pthread_join(3) states:     The pthread_join() function waits for the thread specified by thread to terminate. If that thread has already terminated, then pthread_join() returns immediately. and indeed prior commit 8f11e612 pthread_join() returns immediately. Radostin