From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12981 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: arc4random/csprng Date: Tue, 3 Jul 2018 11:17:56 -0400 Message-ID: <20180703151756.GO1392@brightrain.aerifal.cx> References: <20180702203957.GA9081@brightrain.aerifal.cx> <647a7190-b70b-23a2-9b3c-a24b44fcac99@redhat.com> <20180703144714.GM1392@brightrain.aerifal.cx> <5d28fcf7-b869-175d-c2b7-9c61ef1d40cd@redhat.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1530630975 32758 195.159.176.226 (3 Jul 2018 15:16:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 3 Jul 2018 15:16:15 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: musl@lists.openwall.com To: Florian Weimer Original-X-From: musl-return-12997-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jul 03 17:16:11 2018 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.84_2) (envelope-from ) id 1faN2I-0008Qs-Qj for gllmg-musl@m.gmane.org; Tue, 03 Jul 2018 17:16:10 +0200 Original-Received: (qmail 21554 invoked by uid 550); 3 Jul 2018 15:18:19 -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 21533 invoked from network); 3 Jul 2018 15:18:19 -0000 Content-Disposition: inline In-Reply-To: <5d28fcf7-b869-175d-c2b7-9c61ef1d40cd@redhat.com> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12981 Archived-At: On Tue, Jul 03, 2018 at 05:08:21PM +0200, Florian Weimer wrote: > On 07/03/2018 04:47 PM, Rich Felker wrote: > > >>The main lock (for non-current kernels) is needed for the fork > >>detection counters. Fork detection is required for compatibility > >>with applications which call clone/fork system calls directly, so > > > >How do you consider this supported usage at all? The tid in the TCB > >will be invalid after such a call, and other things may be broken too. > > Right, robust mutexes are quite broken by this. Not just robust. Due to tid reuse, if a single-threaded parent bypasses libc to fork, then exits, the tid that was copied into the child's TCB could get reused for a new thread in the child, thereby allowing two threads to lock the same recursive mutex at the same time. Lots of other versions of this are possible too whenever TCB->tid has a value that's not reserved against reuse. > But it's still quite common to do things with direct system calls, > particularly for setting up containers. > > I have not yet found a case which I couldn't solve with plain fork > (with handlers) and unshare, but that's not what everyone does > unfortunately. I agree you might need direct use of clone sometime for namespace/container stuff, but I don't think there's any way it can be made safe without careful consideration of what you do after the operation before a subsequent execve or _exit. I don't think it makes sense to design big machinery to support doing something that has deeper reasons it can't work, but this is probably partly a difference in philosophy between glibc and musl (see also: dlclose, lazy dtls, lazy tlsdesc, ...). Rich