This is the mail archive of the
mailing list for the GCC project.
Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248]
- From: Jeff Law <law at redhat dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: Cary Coutant <ccoutant at gmail dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, Joe Groff <jgroff at apple dot com>, Binutils <binutils at sourceware dot org>, GCC <gcc at gcc dot gnu dot org>
- Date: Fri, 15 Apr 2016 15:49:04 -0600
- Subject: Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248]
- Authentication-results: sourceware.org; auth=none
- References: <AB592ABD-D6D7-4D2F-A0D6-45738F168DC4 at apple dot com> <BEDD88C6-7F80-45DA-9021-10587244AAE5 at apple dot com> <CAMe9rOq6rmvH458nufzfZnnU_=_n1yysbLzERNy-LWvEmjmN1A at mail dot gmail dot com> <983472E1-A1BC-4970-9CF9-0138A6BAD16D at apple dot com> <CAMe9rOqTTwirymAY6ORp6D_GnCsMc_hYEdy1NbZpG6x5vQc5DQ at mail dot gmail dot com> <6AAD87D2-90F9-4AD7-A195-AC91B76EA6AE at apple dot com> <CAMe9rOqNcYnm1YocG-m7XNDE0g68YQAGe=ULP-G98gaatpxSeA at mail dot gmail dot com> <CAJimCsHfT=cfb4kZysB2W_1HFfOq==TpP=wa47XPGB41MHmGyQ at mail dot gmail dot com> <56FB5061 dot 9010303 at redhat dot com> <20160330143421 dot GM15812 at bubble dot grove dot modra dot org>
On 03/30/2016 08:34 AM, Alan Modra wrote:
Right. Essentially we have to ensure there's one and only one copy of
the variable and that if the shared library and executable take the
address of the variable that the addresses compare equal. Pretty
OK, I'll try to list the technical issues re. pr65248 "Copy relocation
against protected symbol doesn't work".
Given a shared library that defines a variable, and a non-PIC
executable that references that variable, the linker makes a duplicate
of the variable in the executable .dynbss section and arranges to have
the copy initialized by the dynamic loader with a copy relocation.
.dynbss is a linker created section that becomes part of the
executable bss segment. The idea is that at run-time both the
executable and the shared library will use the executable copy of the
variable. It's a rather ancient linker hack to avoid dynamic text
relocations, invented well before symbol visibility.
Which is clearly bad/wrong. But isn't this the state we were in prior
to HJ's change?
The problem with protected visibility variables in shared libraries is
that the shared library continues to access its own copy. So we have
two copies of a variable where the source only contained one variable
definition. (It's not really the copy relocation as such that causes
a problem, but the fact that we have a duplicate in .dynbss.)
ie, the DSO would use non-GOT sequences to access its private copy and
the main executable would reference the duplicate in .dynbss? That led
to two definitions.
After HJ's change, the DSO references via the GOT and we have a single
The problem in that case is we've essentially allowed preemption of a
symbol that was not supposed to be preemptable. Worse yet, all accesses
are going through the GOT in the DSO, which is almost certainly a
ISTM that there is a fundamental incompatibility between protected
visibility and these copy relocations.
Not ideal, but at least we'd get a nice compile/link time error rather
than silently doing the wrong thing in one case or the other.
1) Have the linker emit an error, suggesting that the executable needs
to be PIC to access a protected visibility variable in a shared
library. Pass the pain on to users.
2) Emit dynamic text relocations for non-PIC executable access to
protected visibility variables defined in shared libraries. Makes
executable pages with text relocations non-shared between processes.
(But can be shared again after relocation if two processes have the
Yea, but, ewww.
I'm not a fan of all the rewriting we currently do in the linker; adding
more to deal with this case doesn't seem wise. And we'd have to
replicate it in every target that supports copy relocations. ugh.
3) Teach the linker to edit non-PIC to PIC. I've done this for ppc32,
but it's not very easy for x86 due to the fact that you can't find the
start of an instruction from a relocated field. It also results in
slow code, since PIC sequences are usually larger than non-PIC,
requiring a branch into a patch area and a branch back.
4) Have the compiler always emit PIC for external variable access.
The .dynbss hack could then die a natural death. Coupled with linker
editing of PIC to non-PIC, you'd get correct and reasonably fast code
with perhaps a few nops. Again, x86 has difficulty due to variable
length insns, but this could be solved with marker relocs.
Maybe long term. With the caveats about rewriting above, of course.
It seems like we'd want to stage in the linker changes first, then the
5) HJ's solution. Make the compiler emit the same code for protected
visibility variables in shared libraries as it does for default
visibility variables. ie. shared libraries access their protected
visibility variables via the GOT, which allows the .dynbss hack to
work. Also, modify the dynamic loader to ensure protected visibility
semantics are enforced. (Consider the case of shared lib A that
defines protected visibility var V, and shared lib B that also defines
protected visibility var V, and an executable that references V.
Assuming A is before B in breadth-first order, then the executable and
A should use the .dynbss copy of V, but B should use its own V!) I've
got to hand it to HJ, I think he has all this working properly to
satisfy the semantics of protected visibility.
I'm even less inclined to dump this responsibility onto the dynamic loader.
However, shared library access of protected visibility variables is of
course no quicker than default visibility variables. Which defeats
the main reason to use protected visibility variables in shared
libraries! Note also that it unnecessarily slows down shared library
code using protected visibility variables that are not accessed by the
executable (but perhaps accessed from some other shared library).
Also, I don't believe there is anything to prevent a newly compiled
program from running with an old glibc, which would mean protected
visibility semantics are broken on such a system. To be fair, they
were probably broken on such a system before the linker complained
about non-PIC protected visibility access, anyway.
So in the immediate term, if we drop the problem 65248 patch, we're back
in a state where the DSO and the executable can have two different views
of certain objects. In which case we really need a solution in place to
flag that as an error, which is #1 in your list of mitigations.