Date: Wed, 21 Oct 2009 18:26:36 -0700
From: Andrew Morton <akpm@linux-foundation.org>
To: Dave Jones <davej@redhat.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
       Thomas Gleixner <tglx@linutronix.de>, esandeen@redhat.com,
       cebbert@redhat.com
Subject: Re: Unnecessary overhead with stack protector.
Message-Id: <20091021182636.63edbf72.akpm@linux-foundation.org>
In-Reply-To: <20091015183540.GA8098@redhat.com>
References: <20091015183540.GA8098@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1499
Lines: 33

On Thu, 15 Oct 2009 14:35:41 -0400 Dave Jones <davej@redhat.com> wrote:

> 113c5413cf9051cc50b88befdc42e3402bb92115 introduced a change that
> made CC_STACKPROTECTOR_ALL not-selectable if someone enables CC_STACKPROTECTOR.
> 
> We've noticed in Fedora that this has introduced noticable overhead on
> some functions, including those which don't even have any on-stack variables.
> 
> According to the gcc manpage, -fstack-protector will protect functions with
> as little as 8 bytes of stack usage. So we're introducing a huge amount
> of overhead, to close a small amount of vulnerability (the >0 && <8 case).
> 
> The overhead as it stands right now means this whole option is unusable for
> a distro kernel without reverting the above commit.
> 

This looks like a fairly serious problem to me, but I'm confused by the
commit ID.  February 2008 - is this correct?

If so, this seems like a rather long period of time in which to make such a
discovery.

Also, the Kconfig fiddle didn't cause the problem - it just revealed it. 
The core problem of increased stack usage and text size should already have
been known (to stackprotector developers, at least).  But it sounds like it
wasn't.

So perhaps this was all triggered by a particular gcc version?
--
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/