Building ports with stack-protector

b. f. bf1783 at
Sat Jun 5 21:53:15 UTC 2010

Janne Snabb wrote:
>> AFAIR there was certain performance penalty with stack-protector,
>I think the penalty is small enough. I would assume that someone
>has already made an evaluation on this before turning it on in "make
>buildworld". I was earlier trying to search for a discussion on it,
>but I did not find it on the public mailing lists. Maybe it is


>I remember that some ports built fine but the resulting binaries
>would not work for various reasons when I did my CFLAGS+=-fstack-protector
>experiment a couple of months ago. Unfortunately at that time I did
>not keep a record of which ports were problematic (and I built &&
>tested only a small subset of ports which were the most relevant
>to myself, most of them being network facing server programs).

This is not the first time that this issue has come up.

Jeremie Le Hen pushed through the integration of stack protector
support with the help of others.  If I recall correctly, his original
tests showed ~2-5% penalty for the time required for buildworld.
(Unfortunately, his original website has disappeared.)  This was
thought to be acceptable, and the added security (the stack protector
can be circumvented, but it is much better than nothing at all), and
the fact that it makes finding buffer overflows a bit easier, were
thought to be good reason to enable it by default in most of the base
system.  I thought that the ports committers would then clean up the
ports so that it could be used for the majority of them, too, but this
didn't happen -- even though there are outstanding problems arising
from the fact that stack protection is enabled by default in the base
system of some supported versions of FreeBSD, but not in ports.

I've been building most of my ports with stack protection since 2008,
and most of the failures (~15 of my ~450 installed ports needed to be
patched on i386, and far fewer on amd64) arose from the fact that many
ports don't respect LDFLAGS (the stack-protector flags need to be
passed when linking as well as when compiling).  This needs to be
fixed, and not just for using the stack protector: there has been a
lot of interest in the use of alternative compilers and tool-chains in
ports, and this will require that most ports respect not only CC, CXX,
OBJCOPY, etc.  This may be needed to make ports available on other
architectures, too.  Right now these variables are often ignored (see
how many ports don't pass CPPFLAGS or LDFLAGS during configure or
build, or pass some value that is hard-coded in the port Makefile), or
set to the wrong values in ports/Mk/,
ports/Mk/, /usr/share/mk/, or the port itself.

With reference to Dmitry's patch, I don't think that three different
overlapping variables are really needed, and there is already a
precedent for using "SSP" rather than "STACK_PROTECTOR" in the base
system -- for example, WITHOUT_SSP in src.conf, MK_SSP in a number of
places, and SSP_CFLAGS in /usr/share/mk.  Also, note that support for
the stack protector in the base system, which may affect support in
ports, is not available on several architectures, and can also be
disabled by users in src.conf (see, for example,


More information about the freebsd-ports mailing list