| 1 |
On Thu, Sep 5, 2013 at 7:09 AM, Tom Wijsman <TomWij@g.o> wrote: |
| 2 |
> On Thu, 05 Sep 2013 12:54:27 +0200 |
| 3 |
> Agostino Sarubbo <ago@g.o> wrote: |
| 4 |
> |
| 5 |
>> On Thursday 05 September 2013 12:47:01 Tom Wijsman wrote: |
| 6 |
>> > What I wonder about here is at which cost this does come, when |
| 7 |
>> > looking at the fstack-protector then I see that it "emits extra |
| 8 |
>> > code"; so, now the question is what kind of overhead this causes. |
| 9 |
>> |
| 10 |
>> We use -fstack-protector-all in the hardened profile, so it is not |
| 11 |
>> unknown at all. |
| 12 |
>> |
| 13 |
>> > I am pretty sure security might not be that important on a real time |
| 14 |
>> > system that perhaps isn't connected to the internet; so, besides |
| 15 |
>> > making it the default, we might want to introduce the necessary |
| 16 |
>> > means to turn it off again, by the very least perhaps documentation |
| 17 |
>> > would suffice. |
| 18 |
>> > |
| 19 |
>> > Do you intend to discuss that flag or more generally any security |
| 20 |
>> > flag? |
| 21 |
>> |
| 22 |
>> I just want to point out the thread because other people will have |
| 23 |
>> something to say about. |
| 24 |
> |
| 25 |
> Yes, I am aware of that, I am not saying it is unknown; but I am |
| 26 |
> wondering about those questions: What kind of overhead does this cause? |
| 27 |
> Do you intend to discuss that flag or more generally any security flag? |
| 28 |
> |
| 29 |
|
| 30 |
I suspect that this it is minimal in most cases. I used to use stack |
| 31 |
protection for everything in the early days of amd64 and didn't have |
| 32 |
performance issues when CPUs were considerably slower. The bigger |
| 33 |
issue was compatibility, which has likely improved. I believe many |
| 34 |
distros are using these flags more widely now, so the compatibility |
| 35 |
issues may no longer exist. |
| 36 |
|
| 37 |
Before any decision could be made we would at least need to assess the |
| 38 |
compatibility issues for a broad number of packages. |
| 39 |
|
| 40 |
Sure, we have hardened, but that is no reason to not consider enabling |
| 41 |
the flag by default. If the flag improves security and generally has |
| 42 |
minimal downside then there really is no reason not to do so. |
| 43 |
Hardened includes a lot of security improvements that come at a cost |
| 44 |
of additional configuration, compatibility concerns, etc. |
| 45 |
|
| 46 |
And to reduce the number of replies - I do realize that no compiler |
| 47 |
option is a panacea whether we're talking about optimization or |
| 48 |
security. However, good security includes defense in depth, and stack |
| 49 |
protection is an example of this. Well-audited and designed code |
| 50 |
still benefits from algorithmic protection since no review can be |
| 51 |
certain to eliminate all security problems for a program of anything |
| 52 |
more than trivial complexity. I keep my system up-to-date and yet I |
| 53 |
still run it behind a firewall. |
| 54 |
|
| 55 |
Rich |
Archives