Re: Copy relocations against protected symbols

[Alan Modra <amodra at 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 <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