From owner-freebsd-arch@FreeBSD.ORG Wed Apr 23 20:25:20 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 B556710656AF for ; Wed, 23 Apr 2008 20:25:20 +0000 (UTC) (envelope-from antoine.brodin.freebsd@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.freebsd.org (Postfix) with ESMTP id 4CC5D8FC27 for ; Wed, 23 Apr 2008 20:25:20 +0000 (UTC) (envelope-from antoine.brodin.freebsd@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so4470612pyb.10 for ; Wed, 23 Apr 2008 13:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=W0FgAttSgr7XggeerGvWmE+qLJoYama5shJkhWyeFFo=; b=Wdp1I2s0cms9ucOi/281KqUPz5w3GWwnJBkWpRes/Twr9yBnooE1qeVf5kS4DD+r7fpau6fKSkWSkAMYHeb1zN899HDV7RC3a7Nr3z/NSyVV+tkwNel2OuXRvEqUcsazf2tE56mDZ860L3tDP/Jrj8hnAqr1HOrDuS/pJYEk2DY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=HhtRi5TclYglakUaWC/Y5Oe02KcHg0oA6fAvvN5mcueO6CHxwqHeZuDmjqOg53RZYBlSRMIEA4/3baBcWSA4telxKwaOQE1EkR45ADt61FTQvE+V69ScrqoiSmTlpFY6eO8AeFLQiiZgUUps7f0c+ClZY4OEKwlY1ioB9BO9ynU= Received: by 10.35.77.3 with SMTP id e3mr3643911pyl.7.1208982319304; Wed, 23 Apr 2008 13:25:19 -0700 (PDT) Received: by 10.35.38.6 with HTTP; Wed, 23 Apr 2008 13:25:19 -0700 (PDT) Message-ID: Date: Wed, 23 Apr 2008 22:25:19 +0200 From: "Antoine Brodin" Sender: antoine.brodin.freebsd@gmail.com To: "Jeremie Le Hen" In-Reply-To: <20080423143356.GQ92168@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080418132749.GB4840@obiwan.tataz.chchile.org> <20080423131720.GP92168@obiwan.tataz.chchile.org> <200804230934.42497.jhb@freebsd.org> <20080423143356.GQ92168@obiwan.tataz.chchile.org> X-Google-Sender-Auth: 98bb57cd77be9247 Cc: 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 20:25:20 -0000 On Wed, Apr 23, 2008 at 4:33 PM, Jeremie Le Hen wrote: > 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. Using the following patch, I can boot and run a kernel compiled with -fstack-protector-all (tested on i386, UP) Cheers, Antoine Index: sys/conf/files =================================================================== RCS file: /home/ncvs/src/sys/conf/files,v retrieving revision 1.1294 diff -u -r1.1294 files --- sys/conf/files 21 Apr 2008 10:09:53 -0000 1.1294 +++ sys/conf/files 23 Apr 2008 20:14:01 -0000 @@ -1499,6 +1499,8 @@ kern/sched_4bsd.c optional sched_4bsd kern/sched_ule.c optional sched_ule kern/serdev_if.m standard +kern/stack_protector.c standard \ + compile-with "${NORMAL_C:N-fstack-protector*}" kern/subr_acl_posix1e.c standard kern/subr_autoconf.c standard kern/subr_blist.c standard