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

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

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:

  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.

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.

  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.

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to