-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/07/2013 05:11 PM, Ryan Hill wrote:
> On Sat, 7 Sep 2013 18:10:42 +0000 (UTC)
> Martin Vaeth <va...@mathematik.uni-wuerzburg.de> wrote:
>
>> Ryan Hill <dirtye...@gentoo.org> wrote:
>>>
>>> * -fstack-protector{-all}
>>> No thank you. -fstack-protector has very limited coverage
>>
>> I'd say it covers most cases where bugs can be made,
>> practically without a severe impact on execution time or code size.
>
> The numbers I've seen show a maximum of 5% coverage for code that has a large
> number of functions containing char arrays on the stack. Most code doesn't
> fall
> into that category. Coverage of perl was 0.5%, xorg 5%, kernel 3%. Those are
> really old numbers though. The most recent I've seen is Chromium's coverage
> is
> <2%. There is an upper bound of 8% performance overhead using
> -fstack-protector
> according to the design spec. If you guys are okay with that then we can try
> enabling it for 4.8.1.
Personally I think this would be a great stepping stone. If we add
- -fstack-protector to 4.8.1 it will improve security (only a little I
know) and give us an idea of what issues we may have. After a short
enjoyment of fixing any issues which come up we could more to
- -fstack-protector-strong in 4.9.
Personally I'm using the hardened profile already and find the
performance penalties negligible for a desktop user, and someone trying
to run realtime on defaults is likely suicidal anyway.
Thanks,
Zero
>
>>> * -Wl,-z,relro
>>> Enabled by default since binutils 2.18
>>
>> This gives its real impact on secutiry only when combined with
>>
>> * -Wl,-z,now
>>
>> The latter is not enabled by default AFAIK.
>
> That's a bit misleading. Immediate binding does allow the GOT to be made
> readonly but relro does a lot more than that. In any case this is a firm no.
> The increase in loading times for apps that link lots of libraries is
> significant (if it wasn't, we wouldn't need lazy loading :p). If you want
> full
> relro, enable it yourself or use hardened.
>
>> I would like to suggest also another flag
>>
>> * -Wl,-z,noexecstack
>>
>> This should be the default, but e.g. some broken gcc versions
>> forgot this default when using -flto.
>> I am using this flag since I realized this -flto bug and never
>> had any problems with it.
>
> Well, portage will already tell you if your package installed any binaries
> with
> executable stacks and I don't see many of those warnings that aren't binary
> packages so I think we're good.
>
>>
>>> * -Wl,--hash-style={both,gnu}
>>
>> I don't know what this has to do with security.
>
> I'm just responding to the list on the Ubuntu page.
>
>> However, isn't it time to use "gnu" now for all users? Except for
>> very strange binary-only code it should not cause any problems.
>> The majority of users would not realize a difference but profit
>> from smaller binaries.
>
> Sure, but the sysv hash is teeny and backward compatibility is always nice if
> it's next to free.
>
> Here are some more resources if anyone is interested:
>
> https://wiki.debian.org/Hardening
> https://bugs.archlinux.org/task/18864
> https://wiki.gentoo.org/wiki/Project:Hardened/GNU_stack_quickstart
> http://tk-blog.blogspot.ca/2009/02/relro-not-so-well-known-memory.html
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSK7IJAAoJEKXdFCfdEflKdIkP/3dQpOuzSlzMcXD68oD2L5HP
1ZrgAZzPkBKUOEvlH6WuCIC48k0GdeWCojz4kgo6LM8O3rsn3WRBO1iWbUjSxFja
P8W6bsLJw4t9Tuwk6GJvW0blM66lwQub2+MOynv8DRKloIoQ7yJZmlS1MurcNZFk
AQhl+3xoBpwkXIoR5zCJg0ipMuLV5PdqrtFp7VlPrs3yQfuFw/dxU2+sjo6Kau4a
WvPHzZWco328jVwPHh9F+nFD4F8jKXmBKwy3moOwFkh5a9XnJH3amG7sK37oNWVx
OkQ1pRPaBUyTvNOpA83kQFoa0I6ZWDLK/sCtxtNjadGBKHRwdMWBGN+iZWYH3CEv
uNJBxrJkMbubEpvRK/3nf+fvfa8ChNBbbZlOxyaZ50UCT7KtQ9S0VQWVjYuNYLQy
k9Yzc9jNcEilY5ux0RYqaAosZKso3ePkmbBfZLUs8E2F2C7NwJkhj5tv0AGAWt+n
kN+9MlL/rQhlVh6FtobZVs2DfVxfC87vA0MKJFOoqsOR1w5p2f+mKAUMqJi4jEHJ
ElyJdgIP3KegBIRVp1N9URofA8mIA1fh0Ef3JMx6020LVFXBuO5lihtrLCLR+t5h
PmHrmfbLS1SS/qsN/OavGaYjOhMExcJwNFnuguhNFIcQUdLUmTRzXf7uQ9b1zrbg
ZxLySFNAMubNMQf9Q9j/
=TPkK
-----END PGP SIGNATURE-----
