[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Stack Smash Protection disabled (was HEADS-UP: Stack Smash Protection enabled by default for amd64 and i386)
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.
Main Index |
Thread Index |