[PATCH] Support i386 TLS code sequences without PLT

[H.J. Lu]

On Mon, Jun 6, 2016 at 11:04 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Jun 6, 2016 at 8:01 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>> On 06/03/2016 05:21 PM, H.J. Lu wrote:
>>> We can generate x86-64 TLS code sequences for general and local dynamic
>>> models without PLT, which uses indirect call via GOT:
>>>
>>> call *__tls_get_addr@GOTPCREL(%rip)
>>>
>>> instead of direct call:
>>>
>>> call __tls_get_addr[@PLT]
>>
>> What are the actual pros and cons of this change?
>
> Pros:  improved security and performance since GOT can be
> RELRO and one direct branch is removed.
> Cons: Code size is bigger when there are more than 16 calls
> to __tls_get_addr since direct branch is 4 byte and indirect
> branch is 5 byte. Also there is no lazy binding.
>
>> Does this improve security? Performance?
>>
>> The __tls_get_addr symbol, on x86_64, lives in ld.so, which generally
>> means that all shared objects (GD usage) indirect through their PLT/GOT
>> to make the call. In this model, and because of lazy linking, the
>> PLT-related GOT entries are left read-write to be updated after resolution
>> (ignore the BIND_NOW + RELRO case since in that case we do all of this
>> up front).
>>
>> After your change, without a PLT entry, these symbols can no longer be
>> interposed? The static linker would generate a binding (a got reloc for
>
> It can still be interposed.  Just lazy binding is disabled.
>
>> the symbol which is resolved by the dynamic loader) that cannot be changed,
>> becomes RO after RELRO?
>>
>> Is the security benefit worth the loss of interposition for this symbol?
>
> There is no loss of interposition.
>
>> Is there any performance gains?
>
> One direct branch to PLT entry is removed.
>
> This is what I am checking in.

Here is a similar patch for i386.  Similar pros and cons.  For
i386, since EBX is no longer required to call ___tls_get_addr,
other registers can be used. It will further improve performance
on i386.  I will check it in this week.

-- 
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Support-i386-TLS-code-sequences-without-PLT.patch
Type: text/x-patch
Size: 107018 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20160606/f397a42f/attachment.bin>