Re: Stack Smash Protection disabled (was HEADS-UP: Stack Smash Protection enabled by default for amd64 and i386)

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

David Holland <dholland-current%netbsd.org@localhost> wrote:
>
> ...
>
>  > However, for pure fun, let's look at the "rationale" here. If your
>  > kernel is built without SSP and a vulnerability that it might have
>  > protected against is being exploited, [...]
> 
> Well yes, and here's the thing. You are falling into the standard trap
> of computer security cost/benefit analysis: you're assuming that the
> risk of being attacked is infinite, and therefore the benefit of any
> protection device outweighs its cost regardless of what the cost is.
> 
> There isn't exactly a long history of kernel-level stack-smashing
> attacks. In fact, I can't offhand remember hearing about a single one
> (other than in Windows) -- doubtless someone will refresh my memory,
> but nonetheless it doesn't seem like a very high risk. And therefore,
> it doesn't seem to me that there's much benefit, and in particular,
> not enough to outweigh the cost.

And this is basically the main point, with which I fully agree.

Especially, when there are known issues to solve.  Prevention would be
from low probability hypothetical problems, not the _actual_ ones.  While
performance hit would have immediate effect to everyone.  How about fixing
the known issues first?  Rhetorical question, apparently.

> It's been noted elsewhere that theoretically the overhead of SSP is
> not supposed to be 5%; it's supposed to be negligible. Where is this
> 5% overhead coming from?

This is an interesting question.  Although dancing around each call (well,
more or less invading calling convention) is very ugly.. I was expecting
something ~1% on build.sh workload.

-- 
Mindaugas