1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
This is PIEworld
================
Toolchain modified to build everything that isn't -fPIC, as -fPIE.
gcc:
----
1) Built with PIE-default, SSP-default, RELRO and BIND_NOW
2) Non-PIC crtstuff built -fno-PIE (crtbegin.o, crtend.o)
3) Specs permit -static && -fPIE (but not -pie)
4) New startfile crtbeginTS.o combining crtbeginS.o and crtbeginT.o, for "static PIE"s
glibc:
------
1) Built with PIE-default, SSP off, RELRO and BIND_NOW
SSP-default messes up the dependencies, in different ways on different arches; changes
to glibc would be too invasive for easy maintenance.
2) Non-PIC crtstuff built -fno-PIE (crt1.o - note; crtn.o, crti.o, Scrt1.o all built -fPIC)
3) Make pic-default configure check ignore -fPIE.
4) Link all apps PIE, adjust TLS initialisation to avoid using the TLS before it's ready.
The results are:
crt*S*.o, crtn.o, crti.o & Scrt1.o are -fPIC, all other crtfiles are -fno-PIE.
Code archives lib*.a are -fPIE
Note that since lib*.a are not available -fno-PIE, building static binaries actually creates
binaries containing PIE code, although the executable has a fixed location.
Upgrade path
------------
From hardened gcc-3/glibc-2.3:
1) Switch to vanilla compiler (gcc-config)
2) emerge --oneshot =sys-devel/binutils-2.17
3) USE="-hardened" emerge --oneshot =sys-libs/glibc-2.5
4) USE="-hardened" emerge --oneshot =sys-devel/gcc-4.1.1-r3
5) switch to hardened compiler
6) emerge --oneshot =sys-libs/glibc-2.5
7) emerge --oneshot =sys-devel/gcc-4.1.1-r3
8) emerge -e world :)
Things that can trip up in pieworld
-----------------------------------
* non-PIC assembler. Common in x86 media applications; occurs also in x86 media libraries
although the latter should really be PIC.
* local-exec thread-local storage (TLS). On x86, causes textrels - most arches don't allow
textrels so don't permit local-exec at all in PIC (including PIE).
Investigations
--------------
1) Check all archive lib*.a that don't have a .so - should they be -fPIC rather than -fPIE?
Done:
All those that don't have a .so are best off -fPIC, which is ok for being linked into
shared libraries, and is also ok-enough for use in executables (whereas -fPIE isn't
good for shared libraries).
lib*.a from gcc-4.1.1 are:
libgcc.a built -fPIC
libgcc_eh.a built -fPIC
libffi.a .so equivalent exists
libgcj.a .so equivalent exists
libgcjwt.a .so equivalent exists
libgcov.a built -fPIC
libgfortran.a .so equivalent exists
libgfortranbegin.a Contains fmain.o - looks like only used for executables, so should be ok -fPIE
libgij.a .so equivalent exists
libstdc++.a .so equivalent exists
lib*.a from glibc-2.5 are:
libieee.a shared library (just named '.a')
libmcheck.a shared library (just named '.a')
libc_stubs.a shared library (just named '.a')
libBrokenLocale.a .so equivalent exists
libutil.a .so equivalent exists
librpcsvc.a Built -fPIC (http://sourceware.org/ml/glibc-bugs/2005-07/msg00157.html)
libdl.a .so equivalent exists
librt.a .so equivalent exists
libbsd-compat.a contains only an empty object 'dummy.o' - doesn't matter how it's built
libpthread.a .so equivalent exists
libc.a .so equivalent exists
libg.a contains only an empty object 'dummy.o' - doesn't matter how it's built
libm.a .so equivalent exists
libcrypt.a .so equivalent exists
libanl.a .so equivalent exists
libresolv.a .so equivalent exists
libnsl.a .so equivalent exists
So looks like it's all ok, both in gcc and glibc.
2) glibc-2.5 failures:
For reference, on vanilla x86 the following fail:
linuxthreads/linuxthreads/tst-clock1
linuxthreads/rt/tst-aio9
linuxthreads/rt/tst-aio10
so are ignored for the purposes of analysing failures on hardened.
Some of these may be down to being run in a chroot.
Note also - ppc64 and sparc64 can't have linuxthreads as it doesn't
compile (some changes that are in for nptl have not been back-ported).
x86 (non-hardened kernel):
amd64 (non-hardened kernel):
linuxthreads/libio/tst-wmemstream1
linuxthreads/libio/tst-wmemstream2
linuxthreads/libio/bug-wmemstream1
linuxthreads/dlfcn/default
linuxthreads/linuxthreads/tststatic
linuxthreads/linuxthreads/tst-cancel-static
linuxthreads/linuxthreads/tst-stackguard1-static
linuxthreads/elf/tst-tls1
linuxthreads/elf/tst-tls2
linuxthreads/elf/tst-tls1-static
linuxthreads/elf/tst-tls2-static
linuxthreads/elf/resolvfail
linuxthreads/elf/constload1
nptl/libio/tst-wmemstream1
nptl/libio/tst-wmemstream2
nptl/libio/bug-wmemstream1
nptl/dlfcn/default
nptl/nptl/tst-cancel1
nptl/elf/tst-tls1
nptl/elf/tst-tls2
nptl/elf/tst-tls1-static
nptl/elf/tst-tls2-static
nptl/elf/resolvfail
nptl/elf/constload1
ppc (luna, hardened):
linuxthreads/dlfcn/default
linuxthreads/linuxthreads/tst-context
linuxthreads/rt/tst-mqueue6
linuxthreads/rt/tst-mqueue8
linuxthreads/elf/tst-tls1
linuxthreads/elf/tst-tls2
linuxthreads/elf/resolvfail
linuxthreads/elf/constload1
nptl/dlfcn/default
nptl/nptl/tst-tls2
PaX nptl/nptl/tst-execstack
nptl/rt/tst-cputimer1
nptl/elf/tst-tls1
nptl/elf/tst-tls2
nptl/elf/resolvfail
nptl/elf/constload1
ppc64 (cottonwoord, non-hardened):
nptl/dlfcn/default
nptl/misc/tst-pselect
nptl/nptl/tst-robust7
nptl/nptl/tst-tls2
nptl/elf/tst-tls1
nptl/elf/tst-tls2
nptl/elf/resolvfail
nptl/elf/constload1
sparc64 (bender, non-hardened - linuxthreads not available):
nptl/math/test-fenv
nptl/dlfcn/default
nptl/nptl/tst-eintr1
nptl/nptl/tst-cancel20
nptl/nptl/tst-cancelx20
nptl/elf/tst-tls1
nptl/elf/tst-tls2
nptl/elf/resolvfail
nptl/elf/constload1
|
GitWeb