2014-08-22 18:07, Dimitry Andric wrote:
On 21 Aug 2014, at 18:07, Bryan Drewery <bdrew...@freebsd.org> wrote:
On 8/21/2014 10:53 AM, Bryan Drewery wrote:
On 8/21/2014 5:34 AM, Mark Martinec wrote:
Does clang (in 10-STABLE or CURRENT) support also the
option -fstack-protector-strong ?
Not sure if clang 3.4 has it, but I found a patch for it here:
I'm told that clang 3.5 has support for it. We do not (yet) have 3.5
in
CURRENT.
Indeed, support for -fstack-protector-strong was added after clang 3.4.
Upstream is in the process of releasing clang 3.5; they're currently at
-rc3, and unless something weird happens, the actual release should be
soonish.
That said, it might take a while to get this version into the base
system, because there are some problems to overcome. The major one
being, after 3.4 llvm and clang require a C++11-compatible compiler and
standard library to build. :-)
If there is a great demand for -fstack-protector-strong support, I can
see if it can be backported to our 3.4 version.
Don't know how much demand there is. Just these days I was investigating
what looks like a memory corruption in perl under FreeBSD 10, and
realized
the -fstack-protector-strong would be just the right thing to try first.
(I ended up recompiling perl with gcc48).
Just some random references I came across:
https://en.wikipedia.org/wiki/Buffer_overflow_protection
All Fedora packages are compiled with -fstack-protector since Fedora
Core 5, and -fstack-protector-strong since Fedora 20. [...] All Arch
Linux packages built since 4 May 2014 use -fstack-protector-strong.
https://fedorahosted.org/fesco/ticket/1128
Benefit over the current default "-fstack-protector" =>
"-fstack-protector"
is regarded as "not secure enough" (only "protects" < 2% functions in
Chromium project). "-fstack-protector-strong" hits the balance between
the
over-simplified "-fstack-protector" and over-killing
"-fstack-protector-all".
[...]
The stack-protector option is over-simplified, which ignores pointer
cast,
address computation, while the stack-protector-all is over-killing,
using this option results in too much performance overhead.
http://www.outflux.net/blog/archives/2014/01/27/fstack-protector-strong/
A normal x86_64 “defconfig” build, without stack protector had
a kernel text size of 11430641 bytes with 36110 function bodies.
Adding CONFIG_CC_STACKPROTECTOR_REGULAR increased the kernel text
size to 11468490 (a +0.33% change), with 1015 of 36110 functions
stack-protected (2.81%). Using CONFIG_CC_STACKPROTECTOR_STRONG
increased the kernel text size to 11692790 (+2.24%), with 7401
of 36110 functions stack-protected (20.5%). And 20% is a far-cry
from 100% if support for -fstack-protector-all was added back
to the kernel.
If there is a great demand for -fstack-protector-strong support,
I can see if it can be backported to our 3.4 version.
I guess the answer to that question is whether the goal/wish of
a default WITH_SSP_PORTS / SSP_CFLAGS would be to switch to
the -fstack-protector-strong before clang 3.5 comes into base.
Mark
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
