This is the mail archive of the
mailing list for the binutils project.
Re: Preventing preemption of 'protected' symbols in GNU ld 2.26
- From: Cary Coutant <ccoutant at gmail dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Joe Groff <jgroff at apple dot com>, Binutils <binutils at sourceware dot org>
- Date: Mon, 28 Mar 2016 15:12:07 -0700
- Subject: Re: Preventing preemption of 'protected' symbols in GNU ld 2.26
- Authentication-results: sourceware.org; auth=none
- References: <9106B2FB-BB06-413A-A04D-EEFB992784FA at apple dot com> <CAJimCsEzZ8GDByd8r9x5J9sQ__V0o1mn21FD1xLPe7OhWdikKQ at mail dot gmail dot com> <CAMe9rOqipnAMa-OeYfks6=FYRffxSrcLuJnJD=wX-PjoKcGWRA at mail dot gmail dot com> <CAJimCsFxza3TWVXorqYLa--SfUZ_LznR=m2GkJ_Mq6YZ9Ga3YQ at mail dot gmail dot com> <CAMe9rOphSdEp8mO7OpuEAVpUz-hT8eRb=6RJmaP1XWvDC_UNpQ at mail dot gmail dot com> <CAJimCsHGnHp+s4OXVMt5K=AOsz=nPqY_W7L_M0Ey5rSdK7nk1g at mail dot gmail dot com> <CAMe9rOowzNKqmgf+5A6R-BdEjv2_KAnEYO=PxUH6=MYST_Fu3w at mail dot gmail dot com> <9EFBBDCE-4054-4867-B3E9-9DFE216A234F at apple dot com> <CAMe9rOqqPVeaRZ8SPD-uoxRnHFOCGV3xXFNnDY5ez6xY8uG6hw at mail dot gmail dot com> <CAJimCsFffshMvsDoRq_33Ss8u9Y_Z4y2NKsqDbxJQuO6SyJNbg at mail dot gmail dot com> <CAMe9rOqcw2P_ZU2u-mQ5m7wrVygLKxD3R=KwkxdpiXkeM6o_2g at mail dot gmail dot com>
> Copy relocation and protected symbol are mutually exclusive.
> Since copy relocation is the part of x86 psABIs, it limits
> protected symbol effectiveness on x86. In glibc, we add a
> local alias to symbol we want to protect and access the local
> alias within glibc without GOT.
That can be dangerous -- the copy you reference from within glibc may
not be the same copy that all other code uses. You don't want to do
that in general.
>> - Compilers could also generate tentative PIC-style references, with
>> sufficient relocations to allow the linker to convert the indirect
>> reference to a direct reference when possible (changing the second
>> load into a nop or copy). HP-UX also does this.
> I extended the x86 psABIs with relaxable GOT relocations and
> implemented the similar linker optimization in ld in binutils 2.26
> and gold also implemented the subset of the linker optimization.
Yes; this came in after Sri's changes to enable direct references to
data for -fPIE. It would be interesting to see what benefit remains
after doing the mov-to-lea optimizations.
> Copy relocation can improve performance. Google enabled copy
> relocations for PIE in ld/gold and GCC to improve prefomance by
> up to 5%:
> It is in GCC 5.
I think you're overlooking the key point. The performance improvement
wasn't from COPY relocations -- it was from eliminating the load from
the GOT. Being able to use an occasional COPY relocation in PIE code,
as was always supported for non-PIE code, was done to enable the code
generation change, and make PIE more like non-PIE in that respect.
Sri's measurements were for apps that had up-to-then been built as
non-PIC-non-PIE code. We wanted to convert apps to PIE as a security
improvement, but there was a loss of performance due to the indirect
references through the GOT. There really was no good reason for PIE
code to have to go through the GOT to get to data, so this was just a
way to recover some (or most) of the lost performance.
COPY relocations aren't that significant, but because they weren't
supported for PIE code (a totally arbitrary implementation choice),
they were an obstacle to making the code gen change.
> 1. Compiler accesses protected symbols without GOT in PIC mode
> and marks object files no-copy-relocation-against-protected-symbol.
> 2. Compiler accesses external symbols with GOT in non-PIC mode.
> 3. Linker marks shared object with no-copy-relocation-against-protected-symbol
> if any input files have no-copy-relocation-against-protected-symbol
> 4. Linker optimizes out GOT access if symbol is defined locally
> in executable.
> 5. ld.so checks no-copy-relocation-against-protected-symbol marker
> on shared object to avoid copy relocation against protected symbol
> at run-time.
This looks like it would work, but it seems like over-engineering to
me. The problem you're trying to solve just isn't that significant (or