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
|
NOTES
=====
Non-PIE support is a mess (well, strictly speaking it's broken)
So far, crt{begin,end}.o are now correctly built no-PIE.
However, libgcc.a/libgcc_eh.a, libc.a, libpthread.a, libieee.a, libgcov.a
are built PIE. This ok for linking PIEs, but rubbish for doing non-PIE
links (i.e. vanilla). Also crtfastmath.o is only built once (there's no
crtfastmathS.o) - so we build it PIE.
So, what to do?
For vanilla compiles, we need the .a's built -nopie.
For hardened compiles, we need the .a's built -fPIE - if they ever get used
that way. If we can convince ourselves that when building -fPIE the .so's
are used, then we don't need PIE versions of these .a's.
To do this, add '-nopie' to CFLAGS for libgcc.a in gcc/Makefile.in?
For libc.a - we could treat hardened as a multilib system; with the normal no-PIE
ABI and our PIE ABI - and get glibc to build itself two ways; one for vanilla and
one for hardened. Or, we could try to force all .a's to be built -nopie - this
isn't easy, however, as you can't tell from normal compilation commands whether
it's for a .a or for an executable.
I think the multiple-ABI approach is easier. We could then drop PIE from the
compiler variants, leaving just relro/now and ssp combinations, which don't change
the ABI, and do the -fPIE thing in the compiler wrapper, when ABI is PIE.
I'm thinking of doing MULTLIB_ABIS="x86 x86_pie" and defining
CFLAGS_x86_pie="-fpie -pie"
LDFLAGS_x86_pie="-fpie -pie"
LIBDIR_x86="lib"
LIBDIR_x86_pie="libpie"
note; the gcc-config wrapper adds CFLAGS_x86_pie to the command line, but doesn't look at LDFLAGS_<abi>
Upgrade path for Hardened Gentoo users from glibc-2.3*/gcc-3* to glibc-2.4+/gcc-4.1+
====================================================================================
Note; references to "hardened", "non-hardened" etc refer to the toolchain, not the
kernel.
Generic upgrade instructions
----------------------------
There are separate instructions depending on where you start. Instruction set (2)
should work in all cases, provided a vanilla compiler is set via gcc-config first.
However the most common case will be (1) - which is why it's listed first :)
1) HARDENED SYSTEMS with hardened gcc-3 and glibc-2.3
Going from an existing hardened system (gcc-3.4.6 & glibc-2.3.6 hardened)
.1) emerge --oneshot sys-libs/glibc
build the hardened version of glibc-2.4 (with the gcc-3 hardened compiler)
.2) emerge --oneshot sys-devel/gcc
build the hardened gcc-4.1.1 with the hardened gcc-3.4.6
.3) emerge --oneshot sys-libs/glibc
rebuild the hardened version of glibc-2.4 (with the gcc-4 hardened compiler)
2) NON-HARDENED SYSTEMS with gcc-4.1.1 and glibc-2.4 (no -hardened compiler available)
Going from non-hardened stage3 2006.1:
This starts from non-hardened gcc-4.1.1 and glibc-2.4
.1) Switch profile to the hardened profile
This means remaking the softlink /etc/make.conf to a hardened profile.
Do not confuse this with selecting a hardened compiler with gcc-config (which
you can't do anyway from the standard 2006.1 stage3).
.2) emerge --oneshot sys-libs/glibc
Build glibc with support for both gcc-3 and gcc-4 stack protectiona.
.3) USE="-hardened" emerge --oneshot sys-devel/gcc
Build gcc-4 non-hardened, but including split-specs so it can build
hardened objects later.
.4) gcc-config to the (now available) hardened variant of the compiler.
.5) emerge --oneshot sys-libs/glibc
Build the hardened version of glibc-2.4 (with the gcc-4 hardened compiler)
.6) emerge --oneshot sys-devel/gcc
This will build gcc itself hardened (in particular, building the static libraries PIE)
3) NON-HARDENED SYSTEMS with a -hardened gcc available
.1) gcc-config to the -hardened gcc
.2) emerge --oneshot sys-libs/glibc
Build glibc with support for both gcc-3 and gcc-4 stack protectiona.
.3) emerge --oneshot sys-devel/gcc
build the hardened gcc-4.1.1 with a hardened gcc
.4) emerge --oneshot sys-libs/glibc
rebuild the hardened version of glibc-2.4 (with the gcc-4 hardened compiler)
Platform-specific notes
-----------------------
sparc
For gcc-4 SSP to work, glibc must be 2.4 or higher. Glibc-2.4 is nptl-only, so this means
it's not available on 32-bit sparc (sparcv8).
Toolchain mods for hardened gcc-4.x/glibc-2.4
=============================================
* glibc __stack_chk_fail implementation written so that it's ok when glibc built with SSP
Implement stderr & syslog messaging, SIGKILL and _exit to provide a secure termination
(the one supplied by glibc is for debug purposes only), and all via inline syscalls
avoiding any function calls (which would potentially invoke __stack_chk_fail).
Note; building glibc with ssp-all is causing too many problems at the moment, so for
now it's set to build without ssp.
Sorted out the PIE building better (replaces the filter-ldflags -pie with something
more sensible).
(done) Use SIG_ABRT instead of SIG_KILL - means doing the sigset stuff.
(done) Use INTERNAL_SYSCALL (check vsyscall page isn't user modifiable)
* gcc minispecs for gcc-4.1.1 and gcc-3.4.6, from psm
Much simplified gcc patching for hardened compiler; use of minispecs to generate
the relevant specs files. Involves a few changes in toolchain.eclass and
flag-o-matic.eclass.
* Specs switching handled by the wrappers, rather than the gcc-specs-env patch
(app-admin/eselect-compiler only). This gives us ccache reliability, as for
gcc itself the specs are specified on the command line as normal.
May not be a good idea - doing it gcc itself guarantees it'll happen even if
the wrappers aren't used (is that ever the case?).
Further investigation ongoing to manage filtering; considering doing this by
adjusting GCC_SPECS, although it may be better as a separate variable (perhaps
as part of COMPILER_FEATURES - see bug #128810)
Still cooking
* Look into -DFORTIFY_SOURCE=2, -msecure-plt for ppc
Status summary:
===============
glibc ok (builds itself non-ssp)
gcc ok (ish)
Needs distfile gcc-4.1.1-piepatches-v9.0.6.tar.bz2 from toolchain/distfiles
(or gcc-3.4.6-piepatches-v9.0.5.tar.bz2 for gcc-3.4.6)
|
GitWeb