From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5335 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general,gmane.linux.ports.arm.kernel Subject: Re: Re: Thread pointer changes Date: Fri, 27 Jun 2014 17:55:41 -0400 Message-ID: <20140627215541.GC16724@brightrain.aerifal.cx> References: <20140610072835.GA8466@brightrain.aerifal.cx> <20140611145533.GT179@brightrain.aerifal.cx> <53ADC5B1.6080905@amacapital.net> <20140627200949.GQ32514@n2100.arm.linux.org.uk> <20140627210931.GT23102@port70.net> <20140627213051.GS32514@n2100.arm.linux.org.uk> 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 1403906166 9315 80.91.229.3 (27 Jun 2014 21:56:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Jun 2014 21:56:06 +0000 (UTC) Cc: Szabolcs Nagy , Kees Cook , linux-arm-kernel@lists.infradead.org, Andy Lutomirski To: musl@lists.openwall.com Original-X-From: musl-return-5340-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jun 27 23:55:57 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 1X0e7f-00021Z-7p for gllmg-musl@plane.gmane.org; Fri, 27 Jun 2014 23:55:55 +0200 Original-Received: (qmail 23862 invoked by uid 550); 27 Jun 2014 21:55:54 -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 23854 invoked from network); 27 Jun 2014 21:55:54 -0000 Content-Disposition: inline In-Reply-To: <20140627213051.GS32514@n2100.arm.linux.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5335 gmane.linux.ports.arm.kernel:336471 Archived-At: On Fri, Jun 27, 2014 at 10:30:51PM +0100, Russell King - ARM Linux wrote: > On Fri, Jun 27, 2014 at 11:09:31PM +0200, Szabolcs Nagy wrote: > > i thought the helpers in the kernel can avoid certain memory > > barriers that the userspace has to do on armv6 for atomics > > (and those barriers are deprecated on armv7 so i thought the > > kuser page was better for portable binaries) > > The helpers are provided so that libc can be independent of the CPU > facilities in the machine. The key word there is _libc_, not > applications. > > So, a libc can be built to support the lowest architecture that > someone deems to support, and it may make use of the kuser helpers. > If it does, then you have a libc which requires that the kuser > helpers are always provided by the kernel, and the KUSER_HELPERS > option must never be disabled. If it is disabled, then the libc > will be useless against that kernel. > > However, a libc built against modern architectures should not be > making use of the kuser helpers. We found last year that the > Ubuntu 12.04 glibc did still make use of one kuser helper, and > as such Ubuntu 12.04 also needs KUSER_HELPERS to remain enabled. > > The last combination is that the libc is built for modern architectures > without needing any kuser helpers at all. In this case - and only this > case - the kernel's KUSER_HELPERS option can be disabled should the > system integrator want to increase security. I think you're assuming that libc is used only as a shared library and that the user installs one appropriate for their kernel. This precludes the use of static-linked binaries which are an extremely important usage case for us, especially on ARM where, for example, we want users to be able to make binaries that have a fully-working libc but that can be run on Android, where neither musl nor any other remotely-working libc is installed by default. Obviously some (many) users will opt to build libc with a particular -march where all of the necessary instructions for TLS and atomics are available without help from the kernel. However, if attempting to build a baseline libc that works on any model results in one that can't work on new hardware/kernel, that's a big problem, and exactly the one which I'm trying to solve. Rich