[PATCH] Support x86-64 TLS code sequences without PLT

H.J. Lu hjl.tools@gmail.com
Mon Jun 6 18:04:00 GMT 2016


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.

-- 
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Support-x86-64-TLS-code-sequences-without-PLT.patch
Type: text/x-patch
Size: 111676 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20160606/d953e488/attachment.bin>


More information about the Gcc-patches mailing list