Date: Sat, 5 Jun 2010 21:53:12 +0000 From: "b. f." <bf1783@googlemail.com> To: Janne Snabb <snabb@epipe.com> Cc: freebsd-ports@freebsd.org Subject: Re: Building ports with stack-protector Message-ID: <AANLkTinyoeo1xkam0hgBRebsGRwn5aPZTxfhulWlLgO4@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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 >somewhere. ... >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, and CFLAGS, but also CPP, CPPFLAGS, LDFLAGS, AS, AR, ARFLAGS, LD, 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/bsd.commands.mk, ports/Mk/bsd.port.mk, /usr/share/mk/sys.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, /usr/share/mk/bsd.sys.mk). b.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinyoeo1xkam0hgBRebsGRwn5aPZTxfhulWlLgO4>