Date: Fri, 18 Apr 2008 20:37:24 -0400 From: Garance A Drosehn <gad@FreeBSD.org> To: Jeremie Le Hen <jeremie@le-hen.org>, Max Laier <max@love2party.net> Cc: freebsd-arch@FreeBSD.org Subject: Re: Integration of ProPolice in FreeBSD Message-ID: <p0624080bc42eebc490b9@[128.113.24.47]> In-Reply-To: <20080418204738.GE4840@obiwan.tataz.chchile.org> References: <20080418132749.GB4840@obiwan.tataz.chchile.org> <200804181945.59189.max@love2party.net> <20080418204738.GE4840@obiwan.tataz.chchile.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 10:47 PM +0200 4/18/08, Jeremie Le Hen wrote: >On Fri, Apr 18, 2008, Max Laier wrote: > >> 2) Add support to build kernel/world with SSP enabled - default OFF. >> 3) Solicit testing! > > 4) After some time has passed (and people have had to reinstall > > libc anyways), and enough feedback has been received flip the > > switch to default ON. > >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. > > In light of the the recent "let's save stack space in the kernel", > > I'd like to point out that SSP adds one word to every call. Not > > much, but still. > >Certainly. I would like to hear opinion from other committers if >SSP should be enabled by default. 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. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p0624080bc42eebc490b9>