From owner-freebsd-arch@FreeBSD.ORG Wed Apr 23 14:36:44 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 B1F7D106566B; Wed, 23 Apr 2008 14:36:44 +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 333C48FC29; Wed, 23 Apr 2008 14:36:44 +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 36B843F61E5; Wed, 23 Apr 2008 16:36:43 +0200 (CEST) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id DC8EA3F6248; Wed, 23 Apr 2008 16:36:20 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 6DBFF9BF12; Wed, 23 Apr 2008 14:33:56 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 65A54405B; Wed, 23 Apr 2008 16:33:56 +0200 (CEST) Date: Wed, 23 Apr 2008 16:33:56 +0200 From: Jeremie Le Hen To: John Baldwin Message-ID: <20080423143356.GQ92168@obiwan.tataz.chchile.org> References: <20080418132749.GB4840@obiwan.tataz.chchile.org> <20080423131720.GP92168@obiwan.tataz.chchile.org> <200804230934.42497.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200804230934.42497.jhb@freebsd.org> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Antoine Brodin , 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: Wed, 23 Apr 2008 14:36:44 -0000 Hi John, On Wed, Apr 23, 2008 at 09:34:42AM -0400, John Baldwin wrote: > On Wednesday 23 April 2008 09:17:20 am Jeremie Le Hen wrote: > > This limitation also exists in the kernel. Currently, the kernel canary > > is initialized with: > > > > +/* SI_SUB_EVENTHANDLER is right after SI_SUB_LOCK, used by arc4rand() > > init. */ +SYSINIT(stack_chk, SI_SUB_EVENTHANDLER, SI_ORDER_ANY, > > __stack_chk_init, NULL); > > > > Luckily it seems that for now there is no function on the calling path > > to __stack_chk_init() that GCC deem useful to protect with > > stack-smashing protection. There is nothing that will prevent this to > > occur because of a careless change in the future though. > > > > So obviously, using -fstack-protector-all will break the kernel too. > > > > FWIW, it is easier to handle this in NetBSD as the canary is initialized > > in main(). Nonetheless I suppose it may arise if main() happens to > > return. > > mi_startup() is what runs the sysinit's and is the equivalent of main(). Ok thanks for the info. > > I'm not sure what is the best way to handle this. Should I write special > > rules for those files with > > ${CFLAGS:S/^-fstack-protector-all$/-fstack-protector/g} > > or simply document that building the system with -fstack-protector-all > > is not supported? > > Does GCC provide an attribute that can be applied to a function to disable > stack protection? We could explicitly disable it for the few functions > (mi_startup(), initi386(), etc.) on the call path to mi_startup(). Sorry, I should have mentionned that I've already skimmed over gcc info page and then asked on #gcc on FreeNode for such an atttribute, but there isn't: % 22:16 < Guilt> there are a lot of problems in enabling/disabling % fstack-protector in the mid of the program % 22:16 < Guilt> one is that specs for libssp are taken from the driver % program % 22:17 < Guilt> not the compiler (cc1) and it's not possible to % arbitrarily enable/disable those Ultimately those functions should be moved into separate compilation units. Maybe the current layout is sufficient, I don't know. Would you please give me some hint about the functions that must not be protected? Maybe all the MD stuff? Thank you very much. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org >