[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)
- To: Eric Haszlakiewicz <erh%nimenees.com@localhost>
- Subject: Re: Stack Smash Protection disabled (was HEADS-UP: Stack Smash Protection enabled by default for amd64 and i386)
- From: Thor Lancelot Simon <tls%panix.com@localhost>
- Date: Fri, 13 Nov 2009 11:57:39 -0500
On Fri, Nov 13, 2009 at 10:46:17AM -0600, Eric Haszlakiewicz wrote:
> On Fri, Nov 13, 2009 at 11:38:25AM -0500, Thor Lancelot Simon wrote:
> > On Fri, Nov 13, 2009 at 03:40:19PM +0000, David Holland wrote:
> > > On Fri, Nov 13, 2009 at 08:20:57AM -0500, Steven Bellovin wrote:
> > > > > Note that quite a few packages break with SSP.
> > > >
> > > > Hmm -- why? Buffer overflows that haven't been exploited yet?
> > >
> > > It's allergic to alloca(), and anything equivalent to alloca() like
> > > variable-sized arrays on the stack.
> > This is why I recommended -fstack-protector -Wno-stack-protector as the
> > options to be added to pkgsrc builds.
> > Unfortunately GCC can't do "warn me about X but don't make it fatal even
> > if -Werror is set".
> er.. don't you mean the other way around? I assume you'd want a package
> build to break if it used a construct incompatible with -fstack-protector,
No -- I want to turn stack-protector on for all package builds, but be
sure that those which already set -Werror in their own Makefiles don't
therefore fail to build.
A package which has one source file in it which calls alloca() or uses
a variable-sized array on the stack will still benefit from being
compiled with -fstack-protector -- all the _other_ code in the program
will be protected -- but it would be nice to be able to get warnings,
-fstack-protector without -Wno-stack-protector, however, will cause new
fatal warnings if -Werror is already in the compiler flags, and *that*
will cause some packages to fail to build. -fstack-protector
-Wno-stack-protector should protect everything more than now but leave
I also think we should consider building with -D_FORTIFY_SOURCE=1 but
that does cause some more performance penalty. -D_FORTIFY_SOURCE=2
is more protective but breaks legal code in some cases, so we cannot
use that with pkgsrc.
Many (posibly "most" now) Linux distributions already build their
entire shipped systems including much of what we have in pkgsrc
with compiler flags equivalent to -fstack-protector -D_FORTIFY_SOURCE=1.
Main Index |
Thread Index |