Date: Fri, 22 Aug 2014 19:24:38 +0200 From: Mark Martinec <Mark.Martinec+freebsd@ijs.si> To: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: [CFT] SSP Package Repository available Message-ID: <f81e5aaa642b32e75bb918117bfab627@mailbox.ijs.si> In-Reply-To: <DBC82558-45D6-45E6-A887-016BEE8CC79E@FreeBSD.org> References: <523D79CD.2090302@FreeBSD.org> <53F4CE0E.8040106@FreeBSD.org> <CAE2yjrqjNj1EJNZAa2FTfNyimpKpEXMdEyn9kdFH8PgqrTT8YQ@mail.gmail.com> <b2e18bbe12ba52752d97a2189b436a47@mailbox.ijs.si> <53F615FA.6030604@FreeBSD.org> <53F61949.6050402@FreeBSD.org> <DBC82558-45D6-45E6-A887-016BEE8CC79E@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2014-08-22 18:07, Dimitry Andric wrote: > On 21 Aug 2014, at 18:07, Bryan Drewery <bdrewery@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 ? >>>=20 >>> Not sure if clang 3.4 has it, but I found a patch for it here: >>=20 >> I'm told that clang 3.5 has support for it. We do not (yet) have 3.5=20 >> in >> CURRENT. >=20 > 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. >=20 > 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. :-) >=20 > 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=20 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" =3D>=20 "-fstack-protector" is regarded as "not secure enough" (only "protects" < 2% functions in Chromium project). "-fstack-protector-strong" hits the balance between= =20 the over-simplified "-fstack-protector" and over-killing=20 "-fstack-protector-all". [...] The stack-protector option is over-simplified, which ignores pointer=20 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 =E2=80=9Cdefconfig=E2=80=9D build, without stack protect= or 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f81e5aaa642b32e75bb918117bfab627>