From owner-freebsd-ports@FreeBSD.ORG Sat Jun 5 21:53:15 2010 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07E2D1065675 for ; Sat, 5 Jun 2010 21:53:15 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 936CC8FC0A for ; Sat, 5 Jun 2010 21:53:14 +0000 (UTC) Received: by wyf28 with SMTP id 28so2244036wyf.13 for ; Sat, 05 Jun 2010 14:53:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:cc:content-type; bh=PXgLnmwEzi2ta1rgYS0trnj5B0USX8nEGhVfPZfGAoQ=; b=DDiE2UYWWiE3wM3a+TnhJZysqbYqTE19fouCPrZ0A66ov4R136EvlqRoEj+2QP6Hm0 NlMMXk4y9jw43sLCzPp3mlMhSY7mk02dEXNcYYeagez500UyMRq+XEHFwe5TlqlvgvPE KyWJW5Y5dH66W+s9QY3nuP4eSho0wIwSI/tsA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; b=albCwu2dkfWcWvjzPjTVRqD1zhpSah8HS9w/eXw+v4XpShCS7kyRMnJgV0Xcr1t0Bq Aye3Q2iKCP3FEcS+yl7wyp9EYYJIDBJ0XL6X54GotwNBVncq8XqY5lySft9IRHLgOTBE 5k1XaIhJ6+yCyAnzQLDPRZwKReM2oPhB+EFeE= MIME-Version: 1.0 Received: by 10.216.90.13 with SMTP id d13mr1008992wef.18.1275774792859; Sat, 05 Jun 2010 14:53:12 -0700 (PDT) Received: by 10.216.183.5 with HTTP; Sat, 5 Jun 2010 14:53:12 -0700 (PDT) Date: Sat, 5 Jun 2010 21:53:12 +0000 Message-ID: From: "b. f." To: Janne Snabb Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-ports@freebsd.org Subject: Re: Building ports with stack-protector X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2010 21:53:15 -0000 Janne Snabb wrote: >> AFAIR there was certain performance penalty with stack-protector, > >I think the penalty is small enough. I would assume that someone >has already made an evaluation on this before turning it on in "make >buildworld". I was earlier trying to search for a discussion on it, >but I did not find it on the public mailing lists. Maybe it is >somewhere. ... >I remember that some ports built fine but the resulting binaries >would not work for various reasons when I did my CFLAGS+=-fstack-protector >experiment a couple of months ago. Unfortunately at that time I did >not keep a record of which ports were problematic (and I built && >tested only a small subset of ports which were the most relevant >to myself, most of them being network facing server programs). This is not the first time that this issue has come up. Jeremie Le Hen pushed through the integration of stack protector support with the help of others. If I recall correctly, his original tests showed ~2-5% penalty for the time required for buildworld. (Unfortunately, his original website has disappeared.) This was thought to be acceptable, and the added security (the stack protector can be circumvented, but it is much better than nothing at all), and the fact that it makes finding buffer overflows a bit easier, were thought to be good reason to enable it by default in most of the base system. I thought that the ports committers would then clean up the ports so that it could be used for the majority of them, too, but this didn't happen -- even though there are outstanding problems arising from the fact that stack protection is enabled by default in the base system of some supported versions of FreeBSD, but not in ports. I've been building most of my ports with stack protection since 2008, and most of the failures (~15 of my ~450 installed ports needed to be patched on i386, and far fewer on amd64) arose from the fact that many ports don't respect LDFLAGS (the stack-protector flags need to be passed when linking as well as when compiling). This needs to be fixed, and not just for using the stack protector: there has been a lot of interest in the use of alternative compilers and tool-chains in ports, and this will require that most ports respect not only CC, CXX, and CFLAGS, but also CPP, CPPFLAGS, LDFLAGS, AS, AR, ARFLAGS, LD, OBJCOPY, etc. This may be needed to make ports available on other architectures, too. Right now these variables are often ignored (see how many ports don't pass CPPFLAGS or LDFLAGS during configure or build, or pass some value that is hard-coded in the port Makefile), or set to the wrong values in ports/Mk/bsd.commands.mk, ports/Mk/bsd.port.mk, /usr/share/mk/sys.mk, or the port itself. With reference to Dmitry's patch, I don't think that three different overlapping variables are really needed, and there is already a precedent for using "SSP" rather than "STACK_PROTECTOR" in the base system -- for example, WITHOUT_SSP in src.conf, MK_SSP in a number of places, and SSP_CFLAGS in /usr/share/mk. Also, note that support for the stack protector in the base system, which may affect support in ports, is not available on several architectures, and can also be disabled by users in src.conf (see, for example, /usr/share/mk/bsd.sys.mk). b.