Date: Fri, 27 Jun 2014 17:55:41 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Cc: Szabolcs Nagy <nsz@...t70.net>, Kees Cook <keescook@...omium.org>, linux-arm-kernel@...ts.infradead.org, Andy Lutomirski <luto@...capital.net> Subject: Re: Re: Thread pointer changes 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.