From owner-freebsd-current@FreeBSD.ORG Fri Aug 22 17:24:51 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2BE87948; Fri, 22 Aug 2014 17:24:51 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id C16153D6E; Fri, 22 Aug 2014 17:24:50 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3hfqNc4cpFz184; Fri, 22 Aug 2014 19:24:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla2; t=1408728278; x=1411320279; bh=FNN F8ueDjyw9445L6wg3pN1LEmIpZvxIorQbmul18yE=; b=cfOFrRCqvJtb7S1m9eT oxBqY4aSsq4EsLaXpxn8D/xPNSC9g9yTdUVtPpyJOkOqIZewFiZDgP7E+T4RE/hf hbHtpO2wYUET2NBX8bM5MnCAan1CJj/vEBZaoE/WNnqFQ0SWCNDmBPBPXxQPDehc 3VTjtU9CcXeYt5YTdvKGgEho= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id xX4380njnH3H; Fri, 22 Aug 2014 19:24:38 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP; Fri, 22 Aug 2014 19:24:38 +0200 (CEST) Received: from neli.ijs.si (neli.ijs.si [IPv6:2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by mildred.ijs.si (Postfix) with ESMTP id 3hfqNQ2QFXzJY; Fri, 22 Aug 2014 19:24:38 +0200 (CEST) Received: from neli.ijs.si ([2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Fri, 22 Aug 2014 19:24:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Aug 2014 19:24:38 +0200 From: Mark Martinec To: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: [CFT] SSP Package Repository available Organization: J. Stefan Institute In-Reply-To: References: <523D79CD.2090302@FreeBSD.org> <53F4CE0E.8040106@FreeBSD.org> <53F615FA.6030604@FreeBSD.org> <53F61949.6050402@FreeBSD.org> Message-ID: X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.0.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 17:24:51 -0000 2014-08-22 18:07, Dimitry Andric wrote: > On 21 Aug 2014, at 18:07, Bryan Drewery 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