This is the mail archive of the
mailing list for the binutils project.
Re: Copy relocations against protected symbols
- From: Alan Modra <amodra at gmail dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Thu, 18 Dec 2014 15:15:00 +1030
- Subject: Re: Copy relocations against protected symbols
- Authentication-results: sourceware.org; auth=none
- References: <20141212130509 dot GB23430 at bubble dot grove dot modra dot org> <CAMe9rOqmG2Qbn56kbndm3mZq5c5-fjdJs2mQNXj4GvzRTk3Ahw at mail dot gmail dot com> <20141215010749 dot GA8347 at bubble dot grove dot modra dot org> <CAMe9rOrT3Luw1TDi+Tw4Y=MEhe57wgxxzPNz+tNpp+HT_itBCg at mail dot gmail dot com>
On Sun, Dec 14, 2014 at 06:09:42PM -0800, H.J. Lu wrote:
> On Sun, Dec 14, 2014 at 5:07 PM, Alan Modra <firstname.lastname@example.org> wrote:
> > On Sun, Dec 14, 2014 at 04:16:48AM -0800, H.J. Lu wrote:
> >> On Fri, Dec 12, 2014 at 5:05 AM, Alan Modra <email@example.com> wrote:
> >> > Copy relocs are used in a scheme to avoid dynamic text relocations in
> >> > non-PIC executables that refer to variables defined in shared
> >> > libraries. The idea is to have the linker define any such variable in
> >> > the executable, with a copy reloc copying the initial value, then have
> >> > both the executable and shared library refer to the executable copy.
> >> > If the shared library defines the variable as protected then we have
> >> > two copies of the variable being used.
> >> This caused:
> >> https://sourceware.org/bugzilla/show_bug.cgi?id=17709
> > I think this failure is expected. What we have here is exactly the
> > case my linker change is supposed to prevent: A non-PIC main program
> > without a definition of a given variable and a shared library with a
> > protected definition of said variable. For this we have three choices
> > as far as I can see:
> > 1) The previous linker behaviour of magically creating a copy of the
> > variable in .dynbss, that the main program then uses. This obviously
> > can change program behaviour compared to a main compiled with -fPIC
> > (where you shouldn't get the copy). Incidentally, the vismain/vismod
> > test in glibc is deficient in not testing behaviour when modifying
> > protected variables. If it did, the test would show that the main
> > variable was in fact *none* of the expected ones. The test also has a
> > number of "XXX Possibly enable once fixed" comments. Well, I've just
> > fixed them by making the program invalid. :)
> > 2) As we have now, refusing to link programs that would cause the
> > linker to create copies of protected variables. Or a variant, just
> > warn.
> > 3) Further modify the linker to create dynamic text relocations rather
> > than a copy reloc.
> If we can't find a way to make it work for copy reloc without
> dynamic text relocation by changing ld and ld.so, we should
> disallow protected data in DSO where copy relocation may be
> used to access it.
I doubt we'll find any clever solution. The linker defining a copy of
a variable in .dynbss is quite at odds with protected visibility. For
example, a protected visibility variable allows a compiler to generate
shared library code that accesses the variable without a GOT
indirection. However, it is exactly that GOT indirection that is
needed for ld.so to make the shared library use the .dynbss copy.
Australia Development Lab, IBM