From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 19576 invoked from network); 3 Feb 2021 19:22:06 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 3 Feb 2021 19:22:06 -0000 Received: (qmail 4087 invoked by uid 550); 3 Feb 2021 19:21:59 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 4069 invoked from network); 3 Feb 2021 19:21:59 -0000 Date: Wed, 3 Feb 2021 14:21:46 -0500 From: Rich Felker To: Dominic Chen Cc: musl@lists.openwall.com Message-ID: <20210203192145.GW23432@brightrain.aerifal.cx> References: <62be4b85-4a42-413e-a83f-866eab4d601a@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62be4b85-4a42-413e-a83f-866eab4d601a@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Incorrect thread TID caching On Tue, Feb 02, 2021 at 11:04:23PM -0500, Dominic Chen wrote: > I've been debugging a local port of Chrome using musl, and have > noticed that musl is caching the thread TID in > __pthread_self()->tid, which results in incorrect behavior if the > application calls the clone() libc wrapper or the clone system call, > and then calls libc functions which use the cached TID value, like > raise(). Unfortunately it's really underdocumented and underexplored what a child created with clone() can do. There are definitely limitations -- for example any usage with CLONE_VM or CLONE_THREAD is restricted not to call into libc at all, and might not even be safe whatsoever. However basic usage comparable in semantics to _Fork is probably supposed to work at least as well as _Fork -- in particular calling AS-safe libc functions should work. BTW does Chrom{e,ium} itself do something with raw clone? If so this could be a source of some of the bugs users hit, and it would be great to get a clearer picture on what's happening. > From a quick skim of other libc implementations, both bionic and > glibc don't seem to cache TID, and directly call the gettid system > call inside raise(). I also recall that glibc removed PID caching a > few years ago due to similar issues there as well. So, it seems that > musl should either not cache the TID, or at least update the cached > value after returning from the system call inside the clone() > wrapper (with special handling for CLONE_VM/CLONE_VFORK)? I think the clone() function should be updated to provide whatever contract we expect it to have in the cases where it's valid to use, and this should include the same logic as in _Fork. I'm not sure what we should have it do for unsafe/invalid usage. > Please CC me on replies. OK. Rich