1 |
torsdag 20 oktober 2011 13.17.33 skrev Mike Frysinger: |
2 |
> On Thursday 20 October 2011 12:47:27 Rich Freeman wrote: |
3 |
> > I was trying to draw a contrast between passive things like |
4 |
> > stack-protection and things that really get in your face like MAC. |
5 |
> |
6 |
> the trouble was in the context quoting then ... it sounded like you were |
7 |
> proposing PaX by default |
8 |
> |
9 |
> i am a fan of things that "just work" though which is why i was happy to |
10 |
> merge the fortify source code. most of that checking is done at compile |
11 |
> time, so the runtime overhead is generally small. and in terms of packages |
12 |
> that did break, it was (more often than not) because they were broken |
13 |
> already but we never noticed. |
14 |
> -mike |
15 |
|
16 |
Hi |
17 |
|
18 |
Debian has start to add some hardened features but take a look at ubuntu |
19 |
https://wiki.ubuntu.com/Security/Features |
20 |
|
21 |
Adding ssp support to main would not be a problem for most package works with |
22 |
it. We use same patch as ubuntu's toolchain to enable ssp, but we enable |
23 |
-fstack-protector-all instead of -fstack-protector. You will, however, have |
24 |
some performance penalty enabling it. |
25 |
|
26 |
Adding PIE to main is much harder than ssp. On x86 it will have a high |
27 |
performance penalty and a lot of trouble with asm code. The only arch I would |
28 |
add PIE on is amd64 where it will have only a minor performance penalty and we |
29 |
already have shared libs compile with PIC. The biggest problem we have with |
30 |
PIE on amd64 is asm code in the apps where upstream is not that interested in |
31 |
making the asm PIC aware. It hards to keep the patches up to date when they |
32 |
are not maintained upstream. |
33 |
|
34 |
There are about 30 packages which have problems with PIE. We either add patch |
35 |
to these or else use filter-flags on them. |
36 |
|
37 |
my 2c |
38 |
/Magnus (Zorry) |