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 847 invoked from network); 3 Feb 2021 21:02:09 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 3 Feb 2021 21:02:09 -0000 Received: (qmail 7633 invoked by uid 550); 3 Feb 2021 21:02:06 -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 7610 invoked from network); 3 Feb 2021 21:02:05 -0000 Date: Wed, 3 Feb 2021 16:01:51 -0500 From: Rich Felker To: Dominic Chen Cc: fweimer@redhat.com, musl@lists.openwall.com Message-ID: <20210203210149.GX23432@brightrain.aerifal.cx> References: <62be4b85-4a42-413e-a83f-866eab4d601a@gmail.com> <20210203192145.GW23432@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Incorrect thread TID caching On Wed, Feb 03, 2021 at 03:21:06PM -0500, Dominic Chen wrote: > > On 2/3/2021 2:16 AM, Florian Weimer wrote: > >If you use the clone system call wrapper in threading (not fork/vfork) > >mode, you cannot call any libc functions afterwards, including the > >syscall function. Instead, you have to issue direct system calls. > On 2/3/2021 2:21 PM, Rich Felker wrote: > >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. > > I wasn't aware of this behavior, and didn't see any documentation > about this for the glibc clone() wrapper either. This seems to be a > big footgun, and after looking through the history for this code in > Chrome, it looks like they had a similar issue with glibc too. Yes that's what I mean by underdocumented. > >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. > > The code in question is a unittest for the sandbox, which manually > calls clone with CLONE_NEWPID to fork a child in a PID namespace, > then installs a signal handler and checks that it receives SIGTERM > correctly: https://source.chromium.org/chromium/chromium/src/+/master:sandbox/linux/services/namespace_sandbox_unittest.cc;l=194 > .. But under musl, raise() uses the cached TID value, so the test > eventually times out. OK, raise should probably just be changed here to work even in vforked child since it seems plausible someone will use it there. It's not like saving the syscall actually matters here. But that's independent of the clone() issue. > I missed that the NamespaceSandbox::ForkInNewPidNamespace() function > does manually update the cached TID for glibc after calling the > ForkWithFlags wrapper, so I can just do the same for musl too. This isn't valid; the location is not ABI. You could very well end up clobbering a pointer or something unrelated. The issue should just be fixed on the musl side. Rich