1 |
On Thu, 15 Jun 2017 19:52:07 -0500 Matthias Maier wrote: |
2 |
> > there should be a way of turning these off systematically. the |
3 |
> > advantage of the current hardened gcc specs is that one can switch |
4 |
> > between them using gcc-config. if these are forced on for the default |
5 |
> > profile then there will be no easy way to systematically turn them off. |
6 |
> |
7 |
> No - there won't be an easy way for systematically turning off |
8 |
> SSP and PIE in 17.0 profiles [1,2]. |
9 |
> |
10 |
> The hardened toolchain with its different gcc profiles came from a time |
11 |
> where SSP and PIE were relatively new security features and a certain |
12 |
> amount of fine-grained control was needed. Further, at that time we were |
13 |
> talking about external patches against gcc. Nowadays everything is |
14 |
> upstreamed and (almost) no patches to gcc for hardened profiles are |
15 |
> applied any more. |
16 |
> |
17 |
> Given the fact that all major linux distributions are following the path |
18 |
> of improved default hardening features (see for example [1]) and that we |
19 |
> have been using ssp/pie in hardened profiles for years now the purpose |
20 |
> of fine-grained control over ssp/pie is also highly questionable. |
21 |
> |
22 |
> The consensus at the moment is that PIE and SSP (as well as stricter |
23 |
> linker flags) will soon be standard (or, actually *are* already |
24 |
> standard) compilation options. A per-package override (if absoluetely |
25 |
> needed) is fine - and, in fact, already in place everywhere where |
26 |
> needed. |
27 |
|
28 |
Gentoo is all about choice, remember? :) |
29 |
|
30 |
It is really good to have them by default, it is bad to force them |
31 |
on everyone. Security is not always of paramount importance |
32 |
comparing to other factors, sometimes performance matters more, |
33 |
e.g. in isolated and restricted non-public HPC environment. |
34 |
|
35 |
PIE, SSP may lead up to 8% of performance loss[1]. The |
36 |
stack-protector (especially stack-protector-all or -strong) may |
37 |
cause even more damage. For compute nodes this may be equivalent to |
38 |
millions USD loss (depends on the system scale of course). |
39 |
|
40 |
[1] https://bugs.archlinux.org/task/18864 |
41 |
|
42 |
Best regards, |
43 |
Andrew Savchenko |