Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S937734AbYBWAyp (ORCPT ); Fri, 22 Feb 2008 19:54:45 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S935123AbYBWAqm (ORCPT ); Fri, 22 Feb 2008 19:46:42 -0500 Received: from pentafluge.infradead.org ([213.146.154.40]:60443 "EHLO pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S937054AbYBWAqj (ORCPT ); Fri, 22 Feb 2008 19:46:39 -0500 Date: Fri, 22 Feb 2008 16:46:17 -0800 From: Arjan van de Ven To: Greg KH Cc: linux-kernel@vger.kernel.org, stable@kernel.org, jejb@kernel.org, Justin Forbes , Zwane Mwaikambo , "Theodore Ts'o" , Randy Dunlap , Dave Jones , Chuck Wolber , Chris Wedgwood , Michael Krufky , Chuck Ebbert , Domenico Andreoli , torvalds@linux-foundation.org, akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk, Sam Ravnborg Subject: Re: [patch 34/38] kbuild: allow -fstack-protector to take effect Message-ID: <20080222164617.50c8ec2e@laptopd505.fenrus.org> In-Reply-To: <20080223003133.GI7268@suse.de> References: <20080223001946.979768610@mini.kroah.org> <20080223003133.GI7268@suse.de> Organization: Intel X-Mailer: Claws Mail 3.2.0 (GTK+ 2.12.5; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2829 Lines: 84 On Fri, 22 Feb 2008 16:31:33 -0800 Greg KH wrote: > 2.6.24-stable review patch. If anyone has any objections, please let > us know. not ready for -stable yet. if ever for backporting (doubtful) > > ------------------ > From: Sam Ravnborg > > commit: e06b8b98da071f7dd78fb7822991694288047df0 > > Arjan van de Ven wrote: > === > I just read the excellent LWN writeup of the vmsplice > security thing, and that got me wondering why this attack > wasn't stopped by the CONFIG_CC_STACKPROTECTOR option... > because it plain should have been... > > Some analysis later.. it turns out that the following line > in the top level Makefile, added by you in October 2007, > entirely disables CONFIG_CC_STACKPROTECTOR ;( > With this line removed the exploit will be nicely stopped. > > CFLAGS += $(call cc-option, -fno-stack-protector) > > Now I realize that certain distros have patched gcc to > compensate for their lack of distro wide CFLAGS, and it's > great to work around that... but would there be a way to NOT > disable this for CONFIG_CC_STACKPROTECTOR please? > It would have made this exploit not possible for those kernels > that enable this feature (and that includes distros like Fedora) > === > > Move the assignment to KBUILD_CFLAGS up before including > the arch specific Makefile so arch makefiles may override > the setting. > > Signed-off-by: Sam Ravnborg > Cc: Arjan van de Ven > Signed-off-by: Greg Kroah-Hartman > > --- > Makefile | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > --- a/Makefile > +++ b/Makefile > @@ -507,6 +507,10 @@ else > KBUILD_CFLAGS += -O2 > endif > > +# Force gcc to behave correct even for buggy distributions > +# Arch Makefiles may override this setting > +KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector) > + > include $(srctree)/arch/$(SRCARCH)/Makefile > > ifdef CONFIG_FRAME_POINTER > @@ -520,9 +524,6 @@ KBUILD_CFLAGS += -g > KBUILD_AFLAGS += -gdwarf-2 > endif > > -# Force gcc to behave correct even for buggy distributions > -KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector) > - > # arch Makefile may override CC so keep this after arch Makefile is > included NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) > -print-file-name=include) CHECKFLAGS += $(NOSTDINC_FLAGS) > -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/