MT_HIGH_VECTOR mapping set read-only creating illegal access

[Colin Cross]

On Tue, Apr 19, 2011 at 8:01 PM, Nicolas Pitre <nico at fluxnic.net> wrote:
> On Tue, 19 Apr 2011, Michael Bohan wrote:
>
>> On 4/19/2011 5:21 PM, Nicolas Pitre wrote:
>> > Are you saying that your user space libc was reading at 0xffff0ff0
>> > directly?  I hope not, because if you did so, you clearly abused the
>> > interface and the contract between user space and the kernel.  Here's
>> > what I wrote in the comment right above the related code:
>> >
>> >   * These are segment of kernel provided user code reachable from user space
>> >   * at a fixed address in kernel memory.  This is used to provide user space
>> >   * with some operations which require kernel help because of unimplemented
>> >   * native feature and/or instructions in many ARM CPUs. The idea is for
>> >   * this code to be executed directly in user mode for best efficiency but
>> >   * which is too intimate with the kernel counter part to be left to user
>> >   * libraries.  In fact this code might even differ from one CPU to another
>> >   * depending on the available  instruction set and restrictions like on
>> >   * SMP systems.  In other words, the kernel reserves the right to change
>> >   * this code as needed without warning. Only the entry points and their
>> >   * results are guaranteed to be stable.
>> >
>> > This has been there since April 29th 2005 i.e. 6 years ago.
>>
>> Yes, unfortunately Android appears to do this as an 'optimization' in the case
>> of dynamically linked execs. That is, it skips the helper code all together.
>
> You should find the persons responsible for this aberration and flame
> them with extreme prejudice!  As if this could make any measurable
> difference on any benchmark...
>
> Either you have the hw reg for TLS and may use it directly, or you use
> the provided helper dammit!  I think I'll just move the implementation
> private 0xffff0ff0 location around just to make sure it breaks any user
> code that wrongly started to abuse this interface.
>

I believe the original implementation used the helper, and then it was
modified to skip the helper due to a measured performance impact.
Something to do with cache pressure and a specific vendor GL library
that heavily used get_tls(), I think, but it was before my time.  It
is already fixed on the Android userspace side by defining
ARCH_ARM_HAVE_TLS_REGISTER, which will prevent libc from ever
accessing the private location, and we have dropped the hacks from our
recent kernel trees.