From owner-freebsd-arch@FreeBSD.ORG Sat Apr 19 16:01:17 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3416D106566B; Sat, 19 Apr 2008 16:01:17 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.freebsd.org (Postfix) with ESMTP id BB5518FC0C; Sat, 19 Apr 2008 16:01:16 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id 656833F7D76; Sat, 19 Apr 2008 12:41:24 +0200 (CEST) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 6F6583FA895; Sat, 19 Apr 2008 11:39:15 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 3CD749BF12; Sat, 19 Apr 2008 09:37:01 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 31331405B; Sat, 19 Apr 2008 11:37:01 +0200 (CEST) Date: Sat, 19 Apr 2008 11:37:01 +0200 From: Jeremie Le Hen To: Garance A Drosehn Message-ID: <20080419093701.GJ4840@obiwan.tataz.chchile.org> References: <20080418132749.GB4840@obiwan.tataz.chchile.org> <200804181945.59189.max@love2party.net> <20080418204738.GE4840@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Max Laier , freebsd-arch@FreeBSD.org Subject: Re: Integration of ProPolice in FreeBSD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2008 16:01:17 -0000 Hi, On Fri, Apr 18, 2008 at 08:37:24PM -0400, Garance A Drosehn wrote: > At 10:47 PM +0200 4/18/08, Jeremie Le Hen wrote: > > I will change my patch to make SSP opt-out. This will address > > Marcel's concern too. > > This is a big-enough change that we should ease into it, as Max > suggests. It can be very painful to back out of this, so we don't > want to rush into the change and then find out that we really > really regret it. Honestly, the really painful part when reverting this patch was the disappearance of SSP symbols from libc. But I think this will never happen because they have already been in libc for about a year. Enabling/disabling SSP should not hurt. > You've probably described this somewhere, but let me ask for a little > more info. > > There is "enabled" in the sense that the symbols exist in libc, so > programs *can* be compiled with -fstack-protector-all or > -fstack-protector options. But nothing much really happens until > we start building programs with those options turned on. Once a > program is built with one of those options, then that program has > code in it which will check for stack-smashing in that one program. > > So, in my mind there's the step of "enabling SSP", and then there's > the step of "compiling programs with stack-protection on". I think > we could also split that the second step in stages: > > a) add stack-protection to all setuid programs in the base system. > b) add stack-protection to all "/usr/sbin" programs in the base. > c) add stack-protection to all programs in the base. > d) compile ports with stack-protection on. > > Is that a reasonable breakdown? We could (perhaps) have four > switches, and people could turn on whatever wants they wanted. But > as far as the *default* values, we might want "class A" to default > on for 8.0-release, but the other classes to default off. Then > (maybe) add another class each time we make another release. On Sat, Apr 19, 2008 at 05:14:00PM +1000, Peter Jeremy wrote: > I would agree that a phased approach to enabling SSP is warranted but > I believe it should wind up enabled by default in -current fairly > rapidly. Once the Project has gained more familiarity with SSP and > its > impacts, a decision can be made as to whether it should default to on > or off in -stable and releases. Provided the very little performance overhead [1], my leaning goes toward Peter here. Moreover given that some ports simply don't compile with SSP (qemu, gcc4, etherboot), my personal opinion is it should be enabled by default for ports on -CURRENT in order to spot those out. Note that the port bits have not been provided yet, I will contact portmgr@ for this. [1] http://www.trl.ibm.com/projects/security/ssp/node5.html Thanks. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org >