This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Copy relocations against protected symbols
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Binutils <binutils at sourceware dot org>
- Date: Sun, 14 Dec 2014 18:09:42 -0800
- 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>
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.
--
H.J.