Re: [CFT] SSP Package Repository available

2014-08-22 18:07, Dimitry Andric wrote:
> On 21 Aug 2014, at 18:07, Bryan Drewery <bdrewery_at_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