From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4713 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Transition path for removing lazy init of thread pointer Date: Mon, 24 Mar 2014 13:49:15 -0400 Message-ID: <20140324174915.GA1263@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1395683368 28322 80.91.229.3 (24 Mar 2014 17:49:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Mar 2014 17:49:28 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4717-gllmg-musl=m.gmane.org@lists.openwall.com Mon Mar 24 18:49:37 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WS909-00088e-Jk for gllmg-musl@plane.gmane.org; Mon, 24 Mar 2014 18:49:33 +0100 Original-Received: (qmail 13465 invoked by uid 550); 24 Mar 2014 17:49:31 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 13457 invoked from network); 24 Mar 2014 17:49:31 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4713 Archived-At: I've begun looking at removing lazy-init of the thread pointer, one of the big post-1.0 development items. Since I'm still a bit worried about whether we can ensure that there's always a valid thread pointer without dropping support for some old kernels (which were not officially supported ever, but which de-facto worked for some apps), I've come up with the following conservative roadmap: Phase 1: Initialize the thread pointer at startup, but do not make anything in musl assume that the thread pointer is valid unless the affected code was already assuming the "or" statement: either the thread pointer is already setup, or pthread_self() will successfully set it up. In particular, this phase will leave __errno_location using its own static errno location for the main thread rather than always accessing errno via the thread pointer. This is helpful for the dynamic linker anyway, since we have code that accesses errno early, and otherwise the dynamic linker would need to first initialize a potentially-fake thread pointer at startup, then switch to a new one once the initial TLS size is known. During this phase, we should also try to make sure there is a new mechanism to ensure that pthread_create fails (rather than making a corrupt program state) when the kernel does not support threads; currently, that's done by checking for failure of pthread_self(), which will no longer be the correct way. Phase 2: Add workarounds to setup a valid thread-pointer on older kernels that don't directly support it. On i386 and perhaps x86_64, this could be done with modify_ldt, which has been around since forever. (modify_ldt can't, AFAIK, create a thread-local %fs/%gs mapping, but it can make a valid segment for just the main thread to use.) I'm not sure about other archs though, and whether there are any that matter where we can't set the thread register from userspace. Phase 3: If we can ensure to a satisfactory degree that thread pointer setup never fails, optimize musl-internal things (like errno) to assume he thread pointer is available. This may require special care for the early stages of the dynamic linker. Assuming thread pointer validity is necessary for stack-protector anyway on many archs, and it would allow us to support building libc itself with stack-protector. I'm mostly done with phase 1, but right now it includes an ugly mix of some elements from phases 2 and 3 that shouldn't be touched yet, and it's missing error checks and code for dealing with what happens when the thread pointer setup fails (whether this is fatal should, at phase 1, depend on whether the program/libs need TLS). Rich