Copy relocations against protected symbols
Alan Modra
amodra@gmail.com
Thu Dec 18 04:45:00 GMT 2014
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 <amodra@gmail.com> 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 <amodra@gmail.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.
--
Alan Modra
Australia Development Lab, IBM
More information about the Binutils
mailing list