[PATCH] D20024: [ELF] - Protect first entries of got.plt with RelRo.

[H.J. Lu via llvm-commits]

On Mon, May 9, 2016 at 7:18 AM, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
> On 9 May 2016 at 09:51, H.J. Lu <hjl.tools at gmail.com> wrote:
>> On Mon, May 9, 2016 at 6:47 AM, Rafael Espíndola
>> <rafael.espindola at gmail.com> wrote:
>>>> Since the the link-time address of _DYNAMIC is stored in the first element
>>>> of the GOT as specified by the x86-64 psABI, one can use
>>>>
>>>> movq _GLOBAL_OFFSET_TABLE_(%rip), %rax
>>>>
>>>> to get the link-time address of _DYNAMIC.
>>>
>>> Given that this is being done before relocations, what is the
>>> difference from just using _DYNAMIC?
>>
>> It is the link-time address of _DYNAMIC vs the run-time address of
>>  _DYNAMIC.
>
>
> Do you know how it is used?

  /* Figure out the run-time load address of the dynamic linker itself.  */
  bootstrap_map.l_addr = elf_machine_load_address ();

/* Return the link-time address of _DYNAMIC.  Conveniently, this is the
   first element of the GOT.  This must be inlined in a function which
   uses global data.  */
static inline ElfW(Addr) __attribute__ ((unused))
elf_machine_dynamic (void)
{
  /* This produces an IP-relative reloc which is resolved at link time. */
  extern const ElfW(Addr) _GLOBAL_OFFSET_TABLE_[] attribute_hidden;
  return _GLOBAL_OFFSET_TABLE_[0];
}


/* Return the run-time load address of the shared object.  */
static inline ElfW(Addr) __attribute__ ((unused))
elf_machine_load_address (void)
{
  /* Compute the difference between the runtime address of _DYNAMIC as seen
     by an IP-relative reference, and the link-time address found in the
     special unrelocated first GOT entry.  */
  extern ElfW(Dyn) _DYNAMIC[] attribute_hidden;
  return (ElfW(Addr)) &_DYNAMIC - elf_machine_dynamic ();
}

>
>>> I couldn't find the code in the glibc dynamic linker, but I noticed
>>> musl uses _DYNAMIC and I was able to bootstrap without setting got[0]
>>> with glibc.
>>
>> Did you build ld.so in glibc with it?
>
> No. I would be surprised if we are already able to link it. Can we?
>

Not going to work if a linker doesn't follow the psABI :-).

-- 
H.J.