[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 27 Jun 2014 14:47:38 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Russell King - ARM Linux <linux@....linux.org.uk>
Cc: Szabolcs Nagy <nsz@...t70.net>, musl@...ts.openwall.com,
Kees Cook <keescook@...omium.org>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>
Subject: Re: Re: Thread pointer changes
On Fri, Jun 27, 2014 at 2:30 PM, Russell King - ARM Linux
<linux@....linux.org.uk> 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.
>
>> > Due to that, any ARMv5 or earlier CPU will always have the kuser helper
>> > page. ARMv6 and later may or may not have the kuser helper page, but
>> > there you're really building for a different ABI anyway (VFP-based) and
>> > you also know that you have the thread registers.
>>
>> so is it expected that the libc makes no attempt to provide
>> portable binary interface for armv5 and armv6?
>
> The libc interface that applications make use should not have any
> dependence on whether KUSER_HELPERS is enabled or disabled, the
> presence of that page should be totally invisible to applications.
As of right now, an x86_64 libc can have good performance on any
recent kernel and will work correctly on any kernel. From what you're
saying, it sounds impossible to implement such a thing on ARM without
fiddling with /proc.
--Andy
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.
