Building ports with stack-protector

[Janne Snabb]

On Wed, 2 Jun 2010, Dmitry Marakasov wrote:

> I'd perfer variables to be named and to work similarily to existing
> MAKE_JOBS framework.

Me too. Makes sense. The variable names in my original example were
intended for illustrative purposes only.

> 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.

> It may be implemented by mere copypasting MAKE_JOBS implementation,
> like this: http://people.freebsd.org/~amdmi3/stack-protector.patch

It looks good to me. Simple enough. It would be nice to see this
committed.

> Also note, that unlike MAKE_JOBS (for which build failures are
> non-deterministic), this can probably be tested with a single exp-run
> and all ports marked with STACK_PROTECTOR_{UN,}SAFE. If that's
> considered useful enough as well.

STACK_PROTECTOR_UNSAFE could be automatically added in many cases
where it is needed (if either the port itself or if something that
depends on it fails). But based on my experience, STACK_PROTECTOR_SAFE
should not be added based on a mere build check.

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).

IMHO there should be some sort of human testing effort to mark ports
STACK_PROTECTOR_SAFE, to which I could certainly contribute. One
question is: does it make sense to send-pr this information for
each port, or should the testing results be communicated through
some alternative channel so that the gnats will not be overwhelmed
by PRs related to this (the total number of ports is quite high).

Before starting human testing for STACK_PROTECTOR_SAFE an automatic
test and flagging for STACK_PROTECTOR_UNSAFE is needed. Otherwise
too much of the testing effort goes to marking UNSAFEs which can
be easily determined with an automated test.

--
Janne Snabb / EPIPE Communications
snabb at epipe.com - http://epipe.com/