From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5235 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Thread pointer changes Date: Wed, 11 Jun 2014 10:55:33 -0400 Message-ID: <20140611145533.GT179@brightrain.aerifal.cx> References: <20140610072835.GA8466@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 1402498556 26648 80.91.229.3 (11 Jun 2014 14:55:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Jun 2014 14:55:56 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5240-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jun 11 16:55:50 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 1WujwI-000118-Lb for gllmg-musl@plane.gmane.org; Wed, 11 Jun 2014 16:55:46 +0200 Original-Received: (qmail 26593 invoked by uid 550); 11 Jun 2014 14:55:46 -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 26585 invoked from network); 11 Jun 2014 14:55:45 -0000 Content-Disposition: inline In-Reply-To: <20140610072835.GA8466@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5235 Archived-At: On Tue, Jun 10, 2014 at 03:28:35AM -0400, Rich Felker wrote: > For ARM, I think we should revisit the thread-pointer/atomic inlining > work that was done as a sloppy workaround for kernels without the > kuser_helper page. If the set_thread_area syscall fails (due to an old > kernel that doesn't support it), we can setup a function pointer for > the __aeabi_read_tp function that only supports a single main thread > and returns its thread pointer. Likewise at this stage we could detect > the presence or absence of the kuser_helper page and substitute our > own fallbacks (using the instructions directly) if needed. One thing > that should be checked though is whether there are any kernel versions > which support EABI syscalls but not the thread-pointer setup syscall. > If not, there's really no use in having a fallback for that. These > slides look like they might shed some light on the history: > http://wookware.org/talks/armeabidebconf.pdf According to those slides, the EABI-form syscall convention (which musl requires) was not added to Linux until 2.6.15. The kuser helpers (just thread pointer and atomic cas) were originally added in 2.6.12. Since we already have a bigger reason not to support pre-2.6.15 kernels on ARM, there's no need to worry about whether TLS is supported by the kernel; we can just assume __set_thread_area will always work. As for whether the kuser helper page exists, there are three cases: 1. Normal kuser page - everything available and works. 2. Mainline kernel CONFIG_KUSER_HELPERS disabled - the page is present but filled with a HCF instruction. This is easy to detect. 3. Hardened grsec kernels - the page is completely missing, so attempts to access it fault. And worse yet, most syscalls report EFAULT even if it's present because it's above the task size address limit (in the kernel address range). So far the only way I've found to detect it is process_vm_readv which was not added until 3.2; I'm not sure if there are relevant pre-3.2 grsec kernels with kuser helpers disabled. Rich