1 |
On 10/25/2011 01:59 AM, Ryan Hill wrote: |
2 |
> On Mon, 24 Oct 2011 13:26:01 +0200 |
3 |
> ""Paweł Hajdan, Jr."" <phajdan.jr@g.o> wrote: |
4 |
> |
5 |
>> On 10/24/11 12:58 PM, Anthony G. Basile wrote: |
6 |
>>> Well not totally on their own, they'd report it and we'd have to see |
7 |
>>> what we want to do on an ad hoc basis. |
8 |
>> Fair enough, that's why I suggested to make the hardened spec |
9 |
>> non-default, so that they have to switch it, and include the info in |
10 |
>> emerge --info so we can identify the reason. |
11 |
>> |
12 |
>>> So maybe the first step would be |
13 |
>>> to just build 5 specs: |
14 |
>>> |
15 |
>>> [1] x86_64-pc-linux-gnu-4.4.5 |
16 |
>>> [2] x86_64-pc-linux-gnu-4.4.5-hardenednopie |
17 |
>>> [3] x86_64-pc-linux-gnu-4.4.5-hardenednopiessp |
18 |
>>> [4] x86_64-pc-linux-gnu-4.4.5-hardenednossp |
19 |
>>> [5] x86_64-pc-linux-gnu-4.4.5-vanilla |
20 |
>>> |
21 |
>>> Here [1] = fully hardened. Then ship with no other changes. When bug |
22 |
>>> start to come in, you can deal with each --- some may be fixes at the |
23 |
>>> package level (usually the build system), some may be ebuild fixes, some |
24 |
>>> may need to go into the profiles. |
25 |
>> Right, this is exactly what I'm suggesting, just make [5] the default or |
26 |
>> do some juggling so that [1] is vanilla and [5] is fully hardened or |
27 |
>> something like that. |
28 |
> I would expect x86_64-pc-linux-gnu-4.4.5 to be the vanilla profile and the |
29 |
> fully hardened one to be something like x86_64-pc-linux-gnu-4.4.5-hardened. |
30 |
> |
31 |
|
32 |
Actually, that's what I would expect too, I just cut and pasted the |
33 |
above from my gcc-config on a hardened profile. On vanilla gentoo, it |
34 |
would read: |
35 |
|
36 |
[1] x86_64-pc-linux-gnu-4.4.5 |
37 |
[2] x86_64-pc-linux-gnu-4.4.5-hardenednopie |
38 |
[3] x86_64-pc-linux-gnu-4.4.5-hardenednopiessp |
39 |
[4] x86_64-pc-linux-gnu-4.4.5-hardenednossp |
40 |
[5] x86_64-pc-linux-gnu-4.4.5-hardened |
41 |
|
42 |
Where [1] is vanilla and default. |
43 |
|
44 |
>>> There is one other catch Zorry pointed out, glibc. There are some |
45 |
>>> patches against glibc which would have to go in unconditionally. Take a |
46 |
>>> look at eblit-src_unpack-post() in glibc-2.12.2.ebuild. Currently |
47 |
>>> they're if use hardened. That conditional would be removed. |
48 |
>> Ah, ok. So we have another one. Let's find out our exact constraints: |
49 |
>> |
50 |
>> 1. Are those glibc patches required for gcc built with hardened support? |
51 |
>> Will the gcc build fail without them, or will things fail at runtime |
52 |
>> without them? |
53 |
>> |
54 |
>> 2. Enabling glibc patches would mean enabling PIC by default, right? Is |
55 |
>> that OK? Can it cause breakages? |
56 |
>> |
57 |
>> 3. Am I reading things correctly that PIE is _not_ enabled by default, |
58 |
>> but only when _using_ (i.e. active, not just built) PIE-enabled gcc specs? |
59 |
> I imagine they're conditional for a reason. I just don't know what that |
60 |
> reason is myself. ;) |
61 |
> |
62 |
|
63 |
Zorry's the expert here, so I'll ask him to correct me if I miss |
64 |
anything or get something wrong. |
65 |
|
66 |
You won't get hardening without those patches. So they need to be there |
67 |
if the user switches specs from vanilla to hardened. Here's what they do: |
68 |
|
69 |
1) glibc-2.10-gentoo-chk_fail.c - introduces a wrapper function for |
70 |
__chk_fail() which is triggered on FORTIFY_SOURCES failure (I think, I'm |
71 |
not certain on this one). The wrapped function |
72 |
__hardened_gentoo_chk_fail() writes messages/dumps and kills the process. |
73 |
|
74 |
2) glibc-2.6-gentoo-stack_chk_fail.c - similar but for |
75 |
__stack_chk_fail() and __stack_smash_handler() triggered on stack |
76 |
smashing. Needed at runtime. |
77 |
|
78 |
The later symbol is there when compiling with |
79 |
x86_64-pc-linux-gnu-4.4.5-hardened but not x86_64-pc-linux-gnu-4.4.5. |
80 |
Here's nm test.o for int main(){;return0;} |
81 |
|
82 |
Hardened: |
83 |
|
84 |
<skip stuff> |
85 |
U __libc_start_main@@GLIBC_2.2.5 |
86 |
U __stack_chk_fail@@GLIBC_2.4 < called on stack |
87 |
smashing |
88 |
0000000000201010 A _edata |
89 |
0000000000201020 A _end |
90 |
<skip stuff> |
91 |
|
92 |
Vanilla: |
93 |
|
94 |
<skip stuff> |
95 |
00000000004004f0 T __libc_csu_init |
96 |
U __libc_start_main@@GLIBC_2.2.5 |
97 |
0000000000601018 A _edata |
98 |
0000000000601028 A _end |
99 |
<skip stuff> |
100 |
|
101 |
|
102 |
3) glibc-2.10-hardened-ssp-compat.patch - this is for the older gcc-3 |
103 |
stack smashing protection using __guard() instead of __stack_chk_fail(). |
104 |
|
105 |
4) glibc-2.10-hardened-configure-picdefault.patch + |
106 |
glibc-2.10-hardened-inittls-nosysenter.patch + |
107 |
glibc-2.12-hardened-pie.patch. These are needed at compile time to make |
108 |
sure we build glibc pie and enable pic by default. |
109 |
|
110 |
Binaries are not built pie with vanilla, hardenednopie or |
111 |
hardenednopiessp gcc. You get pie with the other two specs. |
112 |
|
113 |
|
114 |
>>>> Third - can we forcefully disable hardened features in packages that are |
115 |
>>>> not compatible? My assumption is yes, and we should probably print a |
116 |
>>>> warning then. |
117 |
>>> There are a few things you can do here, yes. It is always possible to |
118 |
>>> turn off hardening because the *last* resort solution is just switch |
119 |
>>> compile specs in the ebuild. |
120 |
>> Do you mean calling gcc-config here or something else? If gcc-config, |
121 |
>> it'd be quite hacky and fragile (parallel building of multiple packages, |
122 |
>> having multiple versions of gcc installed). |
123 |
>> |
124 |
>> Is it possible to just pass flags to GCC: disable all this hardened |
125 |
>> stuff? I know you can disable stack protector, but how about PIE or PIC, |
126 |
>> and possible other hardening features? |
127 |
|
128 |
Yes, I was referring to something like gcc-config but I only meant it as |
129 |
an extreme. If you are using x86_64-pc-linux-gnu-4.4.5-hardened, you |
130 |
can pass it the --nopie flag to turn off pie. This can be introduced to |
131 |
the build system via CFLAGS. Like I said, only virtualbox has a build |
132 |
system where I just couldn't get it to accept this flag. But manually |
133 |
switching to hardenednopie works. |
134 |
|
135 |
|
136 |
|
137 |
-- |
138 |
Anthony G. Basile, Ph.D. |
139 |
Gentoo Linux Developer [Hardened] |
140 |
E-Mail : blueness@g.o |
141 |
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 |
142 |
GnuPG ID : D0455535 |