From owner-freebsd-arch@FreeBSD.ORG Sat Apr 19 18:47:28 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 7928F106564A for ; Sat, 19 Apr 2008 18:47:28 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp7.server.rpi.edu (smtp7.server.rpi.edu [128.113.2.227]) by mx1.freebsd.org (Postfix) with ESMTP id 3730A8FC15 for ; Sat, 19 Apr 2008 18:47:28 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp7.server.rpi.edu (8.13.1/8.13.1) with ESMTP id m3JIlO7d021526; Sat, 19 Apr 2008 14:47:26 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20080419093701.GJ4840@obiwan.tataz.chchile.org> References: <20080418132749.GB4840@obiwan.tataz.chchile.org> <200804181945.59189.max@love2party.net> <20080418204738.GE4840@obiwan.tataz.chchile.org> <20080419093701.GJ4840@obiwan.tataz.chchile.org> Date: Sat, 19 Apr 2008 14:47:24 -0400 To: Jeremie Le Hen From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-RPI-SA-Score: undef - spam scanning disabled X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.227 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 18:47:28 -0000 At 11:37 AM +0200 4/19/08, Jeremie Le Hen wrote: > >On Fri, Apr 18, 2008 at 08:37:24PM -0400, Garance A Drosehn wrote: > > >> 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. My comment was talking about how we would roll out SSP for *releases*. I do agree we'd move faster for having developers test it in -current. >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. This part I'm not so sure of. The fact that I'm willing to run freebsd-current to test *freebsd* changes does not mean that I want to be constantly tripping over port-specific problems. I realize that SSP is certainly useful for ports, but that's > 15,000 programs which we probably have little control over. It's going to take quite awhile before we get that sorted out. I guess I don't have any specific recommendation for how to handle SSP in the ports collection. Maybe per-port settings, although that would also get messy. The main ports-developers should decide how SSP should be rolled out through the ports collection. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA