From owner-freebsd-arch@FreeBSD.ORG Wed Apr 23 14:03:36 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 7A96E10656D2 for ; Wed, 23 Apr 2008 14:03:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 5518E8FC1F for ; Wed, 23 Apr 2008 14:03:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (unknown [208.65.91.234]) by elvis.mu.org (Postfix) with ESMTP id 240F21A4D7E; Wed, 23 Apr 2008 07:03:36 -0700 (PDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 23 Apr 2008 09:34:42 -0400 User-Agent: KMail/1.9.7 References: <20080418132749.GB4840@obiwan.tataz.chchile.org> <20080423131720.GP92168@obiwan.tataz.chchile.org> In-Reply-To: <20080423131720.GP92168@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804230934.42497.jhb@freebsd.org> Cc: Antoine Brodin , Jeremie Le Hen 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:03:36 -0000 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(). > 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(). -- John Baldwin