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

Rui Ueyama via llvm-commits llvm-commits at lists.llvm.org
Fri May 6 11:23:46 PDT 2016


Can we simply drop it? I'm wondering if other libc's or dynamic linkers use
it.

On Fri, May 6, 2016 at 11:20 AM, Rafael EspĂ­ndola <
rafael.espindola at gmail.com> wrote:

> I see that musl just does
>
> lea _DYNAMIC(%rip),%rsi
>
> to find its own _DYNAMIC.
>
> I wonder if we can just drop the magical first entries.
>
> Cheers,
> Rafael
>
>
> On 6 May 2016 at 14:12, Rafael EspĂ­ndola <rafael.espindola at gmail.com>
> wrote:
> > Remind me again how the first entry works. From the ABI it looks like
> > .got has to have the first entry be the value of _DYNAMIC and the
> > dynamic linker can use that.
> >
> > But, it looks like it is actually .got.plt that has that. Also, if the
> > dynamic linker can find the .got, it can find the .dynamic section,
> > no?
> >
> > On 6 May 2016 at 13:09, George Rimar <grimar at accesssoftek.com> wrote:
> >> grimar created this revision.
> >> grimar added reviewers: ruiu, rafael.
> >> grimar added subscribers: grimar, llvm-commits.
> >> Herald added a subscriber: joker.eph.
> >>
> >> First entries of got.plt can be protected using RelRo technique,
> >> this patch implements this by shifting got.plt to the memory page,
> >> where relro is active.
> >>
> >> Both gold and bfd do that and it should be good for security.
> >>
> >> http://reviews.llvm.org/D20024
> >>
> >> Files:
> >>   ELF/OutputSections.h
> >>   ELF/Writer.cpp
> >>   test/ELF/aarch64-condb-reloc.s
> >>   test/ELF/aarch64-gnu-ifunc.s
> >>   test/ELF/aarch64-tstbr14-reloc.s
> >>   test/ELF/copy-rel-pie.s
> >>   test/ELF/dynamic-reloc-index.s
> >>   test/ELF/dynamic-reloc.s
> >>   test/ELF/gnu-ifunc-i386.s
> >>   test/ELF/gnu-ifunc.s
> >>   test/ELF/lto/undefined-puts.ll
> >>   test/ELF/mips-26.s
> >>   test/ELF/plt-aarch64.s
> >>   test/ELF/plt-i686.s
> >>   test/ELF/plt.s
> >>   test/ELF/relocation.s
> >>   test/ELF/relro.s
> >>   test/ELF/undef-with-plt-addr.s
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160506/7edec691/attachment.html>


More information about the llvm-commits mailing list