Bug 1576062

Summary: glibc-static appears to be compiled with the -pic option
Product: [Fedora] Fedora Reporter: Tom Horsley <horsley1953>
Component: glibcAssignee: Carlos O'Donell <codonell>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 28CC: aoliva, arjun.is, codonell, dj, fweimer, horsley1953, law, mfabian, pfrankli, rth, siddhesh
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-05-09 08:26:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Tom Horsley 2018-05-08 17:04:47 UTC
Description of problem:

Examination of the relocation code that appear in .o files in /usr/lib64/libc.a should lots of things like PLT relocations. That seems entirely contrary to the purpose (or at least the spirit) of a static glibc.

Just one example:

tomh> ar x /usr/lib64/libc.a fork.o
tomh> readelf --relocs fork.o | fgrep PLT
000000000158  000d00000004 R_X86_64_PLT32    0000000000000000 __nptl_set_robust - 4
000000000170  000f00000004 R_X86_64_PLT32    0000000000000000 __malloc_fork_unlock_c - 4
0000000001f2  001500000004 R_X86_64_PLT32    0000000000000000 __malloc_fork_unlock_p - 4
000000000334  001c00000004 R_X86_64_PLT32    0000000000000000 __malloc_fork_lock_par - 4
00000000033e  001d00000004 R_X86_64_PLT32    0000000000000000 __stack_chk_fail - 4


Version-Release number of selected component (if applicable):
glibc-2.27-8.fc28.x86_64


How reproducible:
100%

Steps to Reproduce:
1.see above
2.
3.

Actual results:
strange reloc codes not normally found in static compiles

Expected results:
no -fpic GOT and PLT references in the .o files

Additional info:

Comment 1 Florian Weimer 2018-05-08 17:54:14 UTC
These relocations are needed for static PIE support.

I think the link editor performs relaxation, and most of these relocations go away if you don't produce a static PIE binary.

Does this address your concern?  Thanks.

Comment 2 Tom Horsley 2018-05-08 18:32:48 UTC
Now I'm just wondering why static PIE is a thing. If you want the (probably spurious) security of a PIE executable why on earth would you link static at all?

My concern is that I have my own "linker" to link patch code into programs I'm debugging and never had to deal with pic-style relocations before. I suppose I can teach it how to handle them, but it is a pain in the patoot :-).

I don't suppose there is an "ld -r" option I could use to transform the pic relocations but still leave me with a relocatable .o file?

Comment 3 Florian Weimer 2018-05-09 08:26:52 UTC
(In reply to Tom Horsley from comment #2)
> Now I'm just wondering why static PIE is a thing. If you want the (probably
> spurious) security of a PIE executable why on earth would you link static at
> all?

There are many reasons for static linking (easier deployment, bootstrapping issues, performance), and PIE is required by most security hardening policies.

Since you use a custom linker, you will either have to recompile glibc without static PIE support, or implement all the required relocations in your linker.