[<prev] [next>] [day] [month] [year] [list]
Message-Id: <1154102778.6416.21.camel@laptopd505.fenrus.org>
Date: Fri, 28 Jul 2006 18:06:18 +0200
From: Arjan van de Ven <arjan@...ux.intel.com>
To: linux-kernel@...r.kernel.org
Cc: ak@...e.de, akpm@...l.org
Subject: [patch 0/5] Add -fstack-protector support the the kernel
This patch series adds support for the gcc 4.1 -fstack-protector feature
to the kernel. While gcc 4.1 supports this feature for userspace, the
patches to support it for the kernel only got added to the gcc tree on
27/7/2006 (eg for 4.2); it is expected that several distributors will
backport this patch to their 4.1 gcc versions.
-fstack-protector is a security feature in gcc that causes "selected"
functions to store a special "canary" value at the start of the
function, just below the return address. At the end of the function,
just before using this return address with the "ret" instruction, this
canary value is compared to the reference value again. If the value of
the stack canary has changed, it is a sign that there has been some
stack corruption (most likely due to a buffer overflow) that has
compromised the integrity of the return address.
Standard, the "selected" functions are those that actually have stack
buffers of at least 8 bytes, this selection is done to limit the
overhead to only those functions with the highest risk potential. There
is an override to enable this for all functions.
On first sight this would not be needed for the kernel, because the
kernel is "perfect" and "has no buffer overflows on the stack". I
thought that too for a long time, but the last year has shown a few
cases where that would have been overly naive.
This feature has some performance overhead (but it's not that incredibly
expensive either) so it should be a configuration option for those who
want this extra security.
For those people who want to use the gcc 4.1 patch, it can be found at
http://www.fenrus.org/stackprotector/gcc41.patch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists