1 |
On 09/07/2013 05:11 PM, Ryan Hill wrote: |
2 |
> On Sat, 7 Sep 2013 18:10:42 +0000 (UTC) |
3 |
> Martin Vaeth <vaeth@××××××××××××××××××××××××.de> wrote: |
4 |
> |
5 |
>> Ryan Hill <dirtyepic@g.o> wrote: |
6 |
>>> * -fstack-protector{-all} |
7 |
>>> No thank you. -fstack-protector has very limited coverage |
8 |
>> I'd say it covers most cases where bugs can be made, |
9 |
>> practically without a severe impact on execution time or code size. |
10 |
> The numbers I've seen show a maximum of 5% coverage for code that has a large |
11 |
> number of functions containing char arrays on the stack. Most code doesn't fall |
12 |
> into that category. Coverage of perl was 0.5%, xorg 5%, kernel 3%. Those are |
13 |
> really old numbers though. The most recent I've seen is Chromium's coverage is |
14 |
> <2%. There is an upper bound of 8% performance overhead using -fstack-protector |
15 |
> according to the design spec. If you guys are okay with that then we can try |
16 |
> enabling it for 4.8.1. |
17 |
> |
18 |
>>> * -Wl,-z,relro |
19 |
>>> Enabled by default since binutils 2.18 |
20 |
>> This gives its real impact on secutiry only when combined with |
21 |
>> |
22 |
>> * -Wl,-z,now |
23 |
>> |
24 |
>> The latter is not enabled by default AFAIK. |
25 |
> That's a bit misleading. Immediate binding does allow the GOT to be made |
26 |
> readonly but relro does a lot more than that. In any case this is a firm no. |
27 |
> The increase in loading times for apps that link lots of libraries is |
28 |
> significant (if it wasn't, we wouldn't need lazy loading :p). If you want full |
29 |
> relro, enable it yourself or use hardened. |
30 |
> |
31 |
>> I would like to suggest also another flag |
32 |
>> |
33 |
>> * -Wl,-z,noexecstack |
34 |
>> |
35 |
>> This should be the default, but e.g. some broken gcc versions |
36 |
>> forgot this default when using -flto. |
37 |
>> I am using this flag since I realized this -flto bug and never |
38 |
>> had any problems with it. |
39 |
> Well, portage will already tell you if your package installed any binaries with |
40 |
> executable stacks and I don't see many of those warnings that aren't binary |
41 |
> packages so I think we're good. |
42 |
> |
43 |
>>> * -Wl,--hash-style={both,gnu} |
44 |
>> I don't know what this has to do with security. |
45 |
> I'm just responding to the list on the Ubuntu page. |
46 |
> |
47 |
>> However, isn't it time to use "gnu" now for all users? Except for |
48 |
>> very strange binary-only code it should not cause any problems. |
49 |
>> The majority of users would not realize a difference but profit |
50 |
>> from smaller binaries. |
51 |
> Sure, but the sysv hash is teeny and backward compatibility is always nice if |
52 |
> it's next to free. |
53 |
> |
54 |
> Here are some more resources if anyone is interested: |
55 |
> |
56 |
> https://wiki.debian.org/Hardening |
57 |
> https://bugs.archlinux.org/task/18864 |
58 |
> https://wiki.gentoo.org/wiki/Project:Hardened/GNU_stack_quickstart |
59 |
> http://tk-blog.blogspot.ca/2009/02/relro-not-so-well-known-memory.html |
60 |
> |
61 |
|
62 |
The hardened team has talked about this in IRC and our general feeling |
63 |
is that adding *just* ssp to vanilla gcc specs is okay. While there are |
64 |
some performance hits, it is generally safe and should cause little |
65 |
problems to our users. The other hardened features, however, have more |
66 |
of an impact and probably don't belong in vanilla as already discussed. |
67 |
|
68 |
-- |
69 |
Anthony G. Basile, Ph.D. |
70 |
Gentoo Linux Developer [Hardened] |
71 |
E-Mail : blueness@g.o |
72 |
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
73 |
GnuPG ID : F52D4BBA |