1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
On 09/07/2013 05:11 PM, Ryan Hill wrote: |
5 |
> On Sat, 7 Sep 2013 18:10:42 +0000 (UTC) |
6 |
> Martin Vaeth <vaeth@××××××××××××××××××××××××.de> wrote: |
7 |
> |
8 |
>> Ryan Hill <dirtyepic@g.o> wrote: |
9 |
>>> |
10 |
>>> * -fstack-protector{-all} |
11 |
>>> No thank you. -fstack-protector has very limited coverage |
12 |
>> |
13 |
>> I'd say it covers most cases where bugs can be made, |
14 |
>> practically without a severe impact on execution time or code size. |
15 |
> |
16 |
> The numbers I've seen show a maximum of 5% coverage for code that has a large |
17 |
> number of functions containing char arrays on the stack. Most code doesn't fall |
18 |
> into that category. Coverage of perl was 0.5%, xorg 5%, kernel 3%. Those are |
19 |
> really old numbers though. The most recent I've seen is Chromium's coverage is |
20 |
> <2%. There is an upper bound of 8% performance overhead using -fstack-protector |
21 |
> according to the design spec. If you guys are okay with that then we can try |
22 |
> enabling it for 4.8.1. |
23 |
|
24 |
Personally I think this would be a great stepping stone. If we add |
25 |
- -fstack-protector to 4.8.1 it will improve security (only a little I |
26 |
know) and give us an idea of what issues we may have. After a short |
27 |
enjoyment of fixing any issues which come up we could more to |
28 |
- -fstack-protector-strong in 4.9. |
29 |
|
30 |
Personally I'm using the hardened profile already and find the |
31 |
performance penalties negligible for a desktop user, and someone trying |
32 |
to run realtime on defaults is likely suicidal anyway. |
33 |
|
34 |
Thanks, |
35 |
Zero |
36 |
|
37 |
> |
38 |
>>> * -Wl,-z,relro |
39 |
>>> Enabled by default since binutils 2.18 |
40 |
>> |
41 |
>> This gives its real impact on secutiry only when combined with |
42 |
>> |
43 |
>> * -Wl,-z,now |
44 |
>> |
45 |
>> The latter is not enabled by default AFAIK. |
46 |
> |
47 |
> That's a bit misleading. Immediate binding does allow the GOT to be made |
48 |
> readonly but relro does a lot more than that. In any case this is a firm no. |
49 |
> The increase in loading times for apps that link lots of libraries is |
50 |
> significant (if it wasn't, we wouldn't need lazy loading :p). If you want full |
51 |
> relro, enable it yourself or use hardened. |
52 |
> |
53 |
>> I would like to suggest also another flag |
54 |
>> |
55 |
>> * -Wl,-z,noexecstack |
56 |
>> |
57 |
>> This should be the default, but e.g. some broken gcc versions |
58 |
>> forgot this default when using -flto. |
59 |
>> I am using this flag since I realized this -flto bug and never |
60 |
>> had any problems with it. |
61 |
> |
62 |
> Well, portage will already tell you if your package installed any binaries with |
63 |
> executable stacks and I don't see many of those warnings that aren't binary |
64 |
> packages so I think we're good. |
65 |
> |
66 |
>> |
67 |
>>> * -Wl,--hash-style={both,gnu} |
68 |
>> |
69 |
>> I don't know what this has to do with security. |
70 |
> |
71 |
> I'm just responding to the list on the Ubuntu page. |
72 |
> |
73 |
>> However, isn't it time to use "gnu" now for all users? Except for |
74 |
>> very strange binary-only code it should not cause any problems. |
75 |
>> The majority of users would not realize a difference but profit |
76 |
>> from smaller binaries. |
77 |
> |
78 |
> Sure, but the sysv hash is teeny and backward compatibility is always nice if |
79 |
> it's next to free. |
80 |
> |
81 |
> Here are some more resources if anyone is interested: |
82 |
> |
83 |
> https://wiki.debian.org/Hardening |
84 |
> https://bugs.archlinux.org/task/18864 |
85 |
> https://wiki.gentoo.org/wiki/Project:Hardened/GNU_stack_quickstart |
86 |
> http://tk-blog.blogspot.ca/2009/02/relro-not-so-well-known-memory.html |
87 |
> |
88 |
|
89 |
-----BEGIN PGP SIGNATURE----- |
90 |
Version: GnuPG v2.0.20 (GNU/Linux) |
91 |
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ |
92 |
|
93 |
iQIcBAEBAgAGBQJSK7IJAAoJEKXdFCfdEflKdIkP/3dQpOuzSlzMcXD68oD2L5HP |
94 |
1ZrgAZzPkBKUOEvlH6WuCIC48k0GdeWCojz4kgo6LM8O3rsn3WRBO1iWbUjSxFja |
95 |
P8W6bsLJw4t9Tuwk6GJvW0blM66lwQub2+MOynv8DRKloIoQ7yJZmlS1MurcNZFk |
96 |
AQhl+3xoBpwkXIoR5zCJg0ipMuLV5PdqrtFp7VlPrs3yQfuFw/dxU2+sjo6Kau4a |
97 |
WvPHzZWco328jVwPHh9F+nFD4F8jKXmBKwy3moOwFkh5a9XnJH3amG7sK37oNWVx |
98 |
OkQ1pRPaBUyTvNOpA83kQFoa0I6ZWDLK/sCtxtNjadGBKHRwdMWBGN+iZWYH3CEv |
99 |
uNJBxrJkMbubEpvRK/3nf+fvfa8ChNBbbZlOxyaZ50UCT7KtQ9S0VQWVjYuNYLQy |
100 |
k9Yzc9jNcEilY5ux0RYqaAosZKso3ePkmbBfZLUs8E2F2C7NwJkhj5tv0AGAWt+n |
101 |
kN+9MlL/rQhlVh6FtobZVs2DfVxfC87vA0MKJFOoqsOR1w5p2f+mKAUMqJi4jEHJ |
102 |
ElyJdgIP3KegBIRVp1N9URofA8mIA1fh0Ef3JMx6020LVFXBuO5lihtrLCLR+t5h |
103 |
PmHrmfbLS1SS/qsN/OavGaYjOhMExcJwNFnuguhNFIcQUdLUmTRzXf7uQ9b1zrbg |
104 |
ZxLySFNAMubNMQf9Q9j/ |
105 |
=TPkK |
106 |
-----END PGP SIGNATURE----- |