From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14270 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 14:43:31 +0100 Message-ID: References: <7e5cec16-6b96-c585-98d4-86cacafbd84e@gmail.com> <20190625232617.GK1506@brightrain.aerifal.cx> <28623527-b159-c1a8-01f2-394049f13836@gmail.com> <20190626112528.GO16415@port70.net> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="237192"; 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 , nsz@port70.net Original-X-From: musl-return-14286-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jun 26 15:43:48 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 1hg8DD-000zc2-Li for gllmg-musl@m.gmane.org; Wed, 26 Jun 2019 15:43:47 +0200 Original-Received: (qmail 28450 invoked by uid 550); 26 Jun 2019 13:43:45 -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 28432 invoked from network); 26 Jun 2019 13:43:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=RC0obShHRPfzpKyesTom0pHxuUoOQ0y8tiYa4UB4/XU=; b=XgFo8y0oo+PP+ajUBKBfR8j2gWmh3WvthjPpnNMQIOLWiOkx/lRKNxzjlQ0OW7NWNF M62RKQQQ/pYCKeclom/VUy/PdyHIqDL3gByWm+svOsKFW2qd3HU0ORCRcQV45JVQqvwy zfwzteImN1wyAaoQmz1qQEKEeSLpITMT/BxknO7TOGBslDj5PTm/z3Nj6eH87/uPmr74 WiQE6EgerfzQv/QE1T2jdC1XF1K0UUEU9lr7idCv6pAbb2rkygxgfOr2826BfpX3mZc1 9CwNDGrX0yoGvrobSxM8yjdP1tZe3hGdqcf8GGjPzW6WmuVet7i5YljyyksNb+UtwWE1 vtlg== 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:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=RC0obShHRPfzpKyesTom0pHxuUoOQ0y8tiYa4UB4/XU=; b=EdidAmUd76yr/beimgU8C7VAVwKbCKHZNMaYSrCgHx1SENjGcROQ9IYAjNY7fsWPfA 54LLx4Na1wEgksRKUHjZoStTuXoTgDQY6B/wl0xP3n2FxNll8uha8br9ufEH1+eCwFLF zeqXdkuQHmeCzZltgfNcOHaFz2PhCR1zlhDaT+y8kwtUELL79Zm2Yh0Ag0Ar5PLdFEi8 lpQTFUvM3Wk27+EKqOV4f6nt5xuwsUIYWv4R4ccgfK6SZcVSbp80WIxwZnTtBiDoQNpW UN3LJ639EIll7/1nhhX4BArUOsUZWCVlRJoYkYGeZzCy3nTZzv1WZ7mGjHmrIhrI91C5 r8Sg== X-Gm-Message-State: APjAAAXl6gxKqOiYJSxDSHRezkqb2ZFxONUalR1A22LeGc5IKAt4mHSg gghc17qdy57lWvIu3Uhv4Rg= X-Google-Smtp-Source: APXvYqyqGwepwXnG4P1Lzd3oG5TN2xDqWkIumo18vLwefcx927guOMbCpk3vFWN7eWKvhMcxq9TowA== X-Received: by 2002:a05:6000:1050:: with SMTP id c16mr3908317wrx.88.1561556613222; Wed, 26 Jun 2019 06:43:33 -0700 (PDT) In-Reply-To: <20190626112528.GO16415@port70.net> Content-Language: en-GB Xref: news.gmane.org gmane.linux.lib.musl.general:14270 Archived-At: On 26/06/2019 12:25, Szabolcs Nagy wrote: > * Radostin Stoyanov [2019-06-26 08:30:34 +0100]: >> On 26/06/2019 00:26, Rich Felker wrote: >>> 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 point is that if *any* libc api is used in the killed thread > or a libc api is used to create that thread fundamentally breaks > assumptions the c runtime may rely on and thus *any* libc call > after the kill is undefined. > > so it's not just pthread_join that's broken but *everything*. > > this affects glibc too and old musl too, even if you may only > observe the particlar pthread_join problem with a current musl. > > if the killed thread was in a signal handler that interrupted > arbitrary libc operation then it obviously breaks everything, > but even without that the libc will hold onto thread specific > internal state and whenever that is used it can cause problems > (in case of musl it is used in pthread_join, glibc uses it e.g. > for set*id operations) Thank you for the explanation Rich and Szabolcs! The test case we have for CRIU is essentially loading a seccomp filter, performing a checkpoint/restore and then verifies that the seccomp filter was restored. Assuming that behaviour of pthread_join is undefined when the thread has been terminated by seccomp, we can refactor the test case to work around the issue. Radostin