This patch series adds support for the gcc -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. (For those who want to know more, see gcc PR 28281)
-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.
I've included fixes for the comments from the last review on lkml, and especially the Makefile
side is now changed to automatically detect if the used gcc has the fix for PR 28281.
Subject: [patch 3/5] Add the canary field to the PDA area and the task struct
From: Arjan van de Ven <[email protected]>
This patch adds the per thread cookie field to the task struct and the PDA.
Also it makes sure that the PDA value gets the new cookie value at context
switch, and that a new task gets a new cookie at task creation time.
Signed-off-by: Arjan van Ven <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
CC: Andi Kleen <[email protected]>
---
arch/x86_64/kernel/process.c | 8 ++++++++
include/asm-x86_64/pda.h | 6 +++++-
include/linux/sched.h | 5 +++++
kernel/fork.c | 5 +++++
4 files changed, 23 insertions(+), 1 deletion(-)
Index: linux-2.6.18-rc4-stackprot/arch/x86_64/kernel/process.c
===================================================================
--- linux-2.6.18-rc4-stackprot.orig/arch/x86_64/kernel/process.c
+++ linux-2.6.18-rc4-stackprot/arch/x86_64/kernel/process.c
@@ -584,6 +584,14 @@ __switch_to(struct task_struct *prev_p,
unlazy_fpu(prev_p);
write_pda(kernelstack,
task_stack_page(next_p) + THREAD_SIZE - PDA_STACKOFFSET);
+#ifdef CONFIG_CC_STACKPROTECTOR
+ write_pda(stack_canary, next_p->stack_canary);
+ /*
+ * Build time only check to make sure the stack_canary is at
+ * offset 40 in the pda; this is a gcc ABI requirement
+ */
+ BUILD_BUG_ON(offsetof(struct x8664_pda, stack_canary) != 40);
+#endif
/*
* Now maybe reload the debug registers
Index: linux-2.6.18-rc4-stackprot/include/asm-x86_64/pda.h
===================================================================
--- linux-2.6.18-rc4-stackprot.orig/include/asm-x86_64/pda.h
+++ linux-2.6.18-rc4-stackprot/include/asm-x86_64/pda.h
@@ -14,7 +14,11 @@ struct x8664_pda {
unsigned long kernelstack; /* 16 */ /* top of kernel stack for current */
unsigned long oldrsp; /* 24 */ /* user rsp for system call */
unsigned long debugstack; /* 32 */ /* #DB/#BP stack. */
- int irqcount; /* 40 */ /* Irq nesting counter. Starts with -1 */
+#ifdef CONFIG_CC_STACKPROTECTOR
+ unsigned long stack_canary; /* 40 */ /* stack canary value */
+ /* gcc-ABI: this canary MUST be at offset 40!!! */
+#endif
+ int irqcount; /* 48 */ /* Irq nesting counter. Starts with -1 */
int cpunumber; /* Logical CPU number */
char *irqstackptr; /* top of irqstack */
int nodenumber; /* number of current node */
Index: linux-2.6.18-rc4-stackprot/include/linux/sched.h
===================================================================
--- linux-2.6.18-rc4-stackprot.orig/include/linux/sched.h
+++ linux-2.6.18-rc4-stackprot/include/linux/sched.h
@@ -819,6 +819,11 @@ struct task_struct {
unsigned did_exec:1;
pid_t pid;
pid_t tgid;
+
+#ifdef CONFIG_CC_STACKPROTECTOR
+ /* Canary value for the -fstack-protector gcc feature */
+ unsigned long stack_canary;
+#endif
/*
* pointers to (original) parent process, youngest child, younger sibling,
* older sibling, respectively. (p->father can be replaced with
Index: linux-2.6.18-rc4-stackprot/kernel/fork.c
===================================================================
--- linux-2.6.18-rc4-stackprot.orig/kernel/fork.c
+++ linux-2.6.18-rc4-stackprot/kernel/fork.c
@@ -45,6 +45,7 @@
#include <linux/cn_proc.h>
#include <linux/delayacct.h>
#include <linux/taskstats_kern.h>
+#include <linux/random.h>
#include <asm/pgtable.h>
#include <asm/pgalloc.h>
@@ -174,6 +175,10 @@ static struct task_struct *dup_task_stru
tsk->thread_info = ti;
setup_thread_stack(tsk, orig);
+#ifdef CONFIG_CC_STACKPROTECTOR
+ tsk->stack_canary = get_random_int();
+#endif
+
/* One for us, one for whoever does the "release_task()" (usually parent) */
atomic_set(&tsk->usage,2);
atomic_set(&tsk->fs_excl, 0);
Subject: [patch 4/5] Add the __stack_chk_fail() function
GCC emits a call to a __stack_chk_fail() function when the stack canary is
not matching the expected value.
Since this is a bad security issue; lets panic the kernel rather than limping
along; the kernel really can't be trusted anymore when this happens.
Signed-off-by: Arjan van de Ven <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
CC: Andi Kleen <[email protected]>
---
kernel/panic.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
Index: linux-2.6.18-rc4-stackprot/kernel/panic.c
===================================================================
--- linux-2.6.18-rc4-stackprot.orig/kernel/panic.c
+++ linux-2.6.18-rc4-stackprot/kernel/panic.c
@@ -269,3 +269,15 @@ void oops_exit(void)
{
do_oops_enter_exit();
}
+
+#ifdef CONFIG_CC_STACKPROTECTOR
+/*
+ * Called when gcc's -fstack-protector feature is used, and
+ * gcc detects corruption of the on-stack canary value
+ */
+void __stack_chk_fail(void)
+{
+ panic("stack-protector: Kernel stack is corrupted");
+}
+EXPORT_SYMBOL(__stack_chk_fail);
+#endif
Subject: [patch 1/5] Add comments to the PDA structure to annotate offsets
From: Arjan van de Ven <[email protected]>
Change the comments in the pda structure to make the first fields to have
their offset documented and to have the comments aligned.
The stack protector series needs a field at offset 40 (gcc ABI); annotate
upto 40 for that reason.
Signed-off-by: Arjan van de Ven <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
CC: Andi Kleen <[email protected]>
---
include/asm-x86_64/pda.h | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
Index: linux-2.6.18-rc4-stackprot/include/asm-x86_64/pda.h
===================================================================
--- linux-2.6.18-rc4-stackprot.orig/include/asm-x86_64/pda.h
+++ linux-2.6.18-rc4-stackprot/include/asm-x86_64/pda.h
@@ -9,14 +9,12 @@
/* Per processor datastructure. %gs points to it while the kernel runs */
struct x8664_pda {
- struct task_struct *pcurrent; /* Current process */
- unsigned long data_offset; /* Per cpu data offset from linker address */
- unsigned long kernelstack; /* top of kernel stack for current */
- unsigned long oldrsp; /* user rsp for system call */
-#if DEBUG_STKSZ > EXCEPTION_STKSZ
- unsigned long debugstack; /* #DB/#BP stack. */
-#endif
- int irqcount; /* Irq nesting counter. Starts with -1 */
+ struct task_struct *pcurrent; /* 0 */ /* Current process */
+ unsigned long data_offset; /* 8 */ /* Per cpu data offset from linker address */
+ unsigned long kernelstack; /* 16 */ /* top of kernel stack for current */
+ unsigned long oldrsp; /* 24 */ /* user rsp for system call */
+ unsigned long debugstack; /* 32 */ /* #DB/#BP stack. */
+ int irqcount; /* 40 */ /* Irq nesting counter. Starts with -1 */
int cpunumber; /* Logical CPU number */
char *irqstackptr; /* top of irqstack */
int nodenumber; /* number of current node */
Subject: [patch 2/5] Add the Kconfig option for the stackprotector feature
From: Arjan van de Ven <[email protected]>
This patch adds the config options for -fstack-protector.
Signed-off-by: Arjan van de Ven <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
CC: Andi Kleen <[email protected]>
---
arch/x86_64/Kconfig | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
Index: linux-2.6.18-rc4-stackprot/arch/x86_64/Kconfig
===================================================================
--- linux-2.6.18-rc4-stackprot.orig/arch/x86_64/Kconfig
+++ linux-2.6.18-rc4-stackprot/arch/x86_64/Kconfig
@@ -522,6 +522,30 @@ config SECCOMP
If unsure, say Y. Only embedded should say N here.
+config CC_STACKPROTECTOR
+ bool "Enable -fstack-protector buffer overflow detection (EXPRIMENTAL)"
+ depends on EXPERIMENTAL
+ help
+ This option turns on the -fstack-protector GCC feature. This
+ feature puts, at the beginning of critical functions, a canary
+ value on the stack just before the return address, and validates
+ the value just before actually returning. Stack based buffer
+ overflows (that need to overwrite this return address) now also
+ overwrite the canary, which gets detected and the attack is then
+ neutralized via a kernel panic.
+
+ This feature requires gcc version 4.2 or above, or a distribution
+ gcc with the feature backported. Older versions are automatically
+ detected and for those versions, this configuration option is ignored.
+
+config CC_STACKPROTECTOR_ALL
+ bool "Use stack-protector for all functions"
+ depends on CC_STACKPROTECTOR
+ help
+ Normally, GCC only inserts the canary value protection for
+ functions that use large-ish on-stack buffers. By enabling
+ this option, GCC will be asked to do this for ALL functions.
+
source kernel/Kconfig.hz
config REORDER
Subject: [patch 5/5] Add the -fstack-protector option to the CFLAGS
From: Arjan van de Ven <[email protected]>
Add a feature check that checks that the gcc compiler has stack-protector
support and has the bugfix for PR28281 to make this work in kernel mode.
The easiest solution I could find was to have a shell script in scripts/
to do the detection; if needed we can make this fancier in the future
without making the makefile too complex.
Signed-off-by: Arjan van de Ven <[email protected]>
CC: Andi Kleen <[email protected]>
CC: Sam Ravnborg <[email protected]>
---
arch/x86_64/Makefile | 3 +++
scripts/gcc-x86_64-has-stack-protector.sh | 8 ++++++++
2 files changed, 11 insertions(+)
Index: linux-2.6.18-rc4-stackprot/arch/x86_64/Makefile
===================================================================
--- linux-2.6.18-rc4-stackprot.orig/arch/x86_64/Makefile
+++ linux-2.6.18-rc4-stackprot/arch/x86_64/Makefile
@@ -55,6 +55,9 @@ cflags-y += $(call cc-option,-funit-at-a
# prevent gcc from generating any FP code by mistake
cflags-y += $(call cc-option,-mno-sse -mno-mmx -mno-sse2 -mno-3dnow,)
+cflags-$(CONFIG_CC_STACKPROTECTOR) += $(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-x86_64-has-stack-protector.sh $(CC) -fstack-protector )
+cflags-$(CONFIG_CC_STACKPROTECTOR_ALL) += $(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-x86_64-has-stack-protector.sh $(CC) -fstack-protector-all )
+
CFLAGS += $(cflags-y)
CFLAGS_KERNEL += $(cflags-kernel-y)
AFLAGS += -m64
Index: linux-2.6.18-rc4-stackprot/scripts/gcc-x86_64-has-stack-protector.sh
===================================================================
--- /dev/null
+++ linux-2.6.18-rc4-stackprot/scripts/gcc-x86_64-has-stack-protector.sh
@@ -0,0 +1,6 @@
+#!/bin/sh
+
+echo "int foo(void) { char X[200]; return 3; }" | $1 -S -xc -c -O0 -mcmodel=kernel -fstack-protector - -o - | grep -q "%gs"
+if [ "$?" -eq "0" ] ; then
+ echo $2
+fi
On Wed, Aug 16, 2006 at 06:50:38PM +0200, Arjan van de Ven wrote:
> Subject: [patch 2/5] Add the Kconfig option for the stackprotector feature
> From: Arjan van de Ven <[email protected]>
>
> This patch adds the config options for -fstack-protector.
>
> Signed-off-by: Arjan van de Ven <[email protected]>
> Signed-off-by: Ingo Molnar <[email protected]>
> CC: Andi Kleen <[email protected]>
>
> ---
> arch/x86_64/Kconfig | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> Index: linux-2.6.18-rc4-stackprot/arch/x86_64/Kconfig
> ===================================================================
> --- linux-2.6.18-rc4-stackprot.orig/arch/x86_64/Kconfig
> +++ linux-2.6.18-rc4-stackprot/arch/x86_64/Kconfig
> @@ -522,6 +522,30 @@ config SECCOMP
>
> If unsure, say Y. Only embedded should say N here.
>
> +config CC_STACKPROTECTOR
> + bool "Enable -fstack-protector buffer overflow detection (EXPRIMENTAL)"
> + depends on EXPERIMENTAL
> + help
> + This option turns on the -fstack-protector GCC feature. This
> + feature puts, at the beginning of critical functions, a canary
> + value on the stack just before the return address, and validates
> + the value just before actually returning. Stack based buffer
> + overflows (that need to overwrite this return address) now also
> + overwrite the canary, which gets detected and the attack is then
> + neutralized via a kernel panic.
> +
> + This feature requires gcc version 4.2 or above, or a distribution
> + gcc with the feature backported. Older versions are automatically
> + detected and for those versions, this configuration option is ignored.
>...
Please add something like
This feature adds some extra security with a moderate
performance overhead.
to make it easier for a user to decide whether or not to enable this
option.
cu
Adrian
--
Gentoo kernels are 42 times more popular than SUSE kernels among
KLive users (a service by SUSE contractor Andrea Arcangeli that
gathers data about kernels from many users worldwide).
There are three kinds of lies: Lies, Damn Lies, and Statistics.
Benjamin Disraeli
On Wed, Aug 16, 2006 at 06:53:17PM +0200, Arjan van de Ven wrote:
> Subject: [patch 5/5] Add the -fstack-protector option to the CFLAGS
> From: Arjan van de Ven <[email protected]>
>
> Add a feature check that checks that the gcc compiler has stack-protector
> support and has the bugfix for PR28281 to make this work in kernel mode.
> The easiest solution I could find was to have a shell script in scripts/
> to do the detection; if needed we can make this fancier in the future
> without making the makefile too complex.
>
> Signed-off-by: Arjan van de Ven <[email protected]>
> CC: Andi Kleen <[email protected]>
> CC: Sam Ravnborg <[email protected]>
>
> ---
> arch/x86_64/Makefile | 3 +++
> scripts/gcc-x86_64-has-stack-protector.sh | 8 ++++++++
> 2 files changed, 11 insertions(+)
>
> Index: linux-2.6.18-rc4-stackprot/arch/x86_64/Makefile
> ===================================================================
> --- linux-2.6.18-rc4-stackprot.orig/arch/x86_64/Makefile
> +++ linux-2.6.18-rc4-stackprot/arch/x86_64/Makefile
> @@ -55,6 +55,9 @@ cflags-y += $(call cc-option,-funit-at-a
> # prevent gcc from generating any FP code by mistake
> cflags-y += $(call cc-option,-mno-sse -mno-mmx -mno-sse2 -mno-3dnow,)
>
> +cflags-$(CONFIG_CC_STACKPROTECTOR) += $(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-x86_64-has-stack-protector.sh $(CC) -fstack-protector )
> +cflags-$(CONFIG_CC_STACKPROTECTOR_ALL) += $(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-x86_64-has-stack-protector.sh $(CC) -fstack-protector-all )
> +
I agree with the pricinple on hiding the check in the script.
But please try to keep lines within 80 coloumn limit.
something like this which is functionality wise equal:
stack-protector = $(shell $(CONFIG_SHELL) \
$(srctree)/scripts/gcc-x86_64-has-stack-protector.sh $(1))
cflags-$(CONFIG_CC_STACKPROTECTOR) += \
$(call stack-protector, $(CC) -fstack-protector)
cflags-$(CONFIG_CC_STACKPROTECTOR_ALL) += \
$(call stack-protector, $(CC) -fstack-protector-all)
I do not like the broken lines either but with these long CONFIG_ names
it is needed.
Otherwised Acked-by: Sam Ravnborg <[email protected]>
PS - above is untested...
Sam
On Wed, 2006-08-16 at 20:55 +0200, Sam Ravnborg wrote:
> stack-protector = $(shell $(CONFIG_SHELL) \
>
> $(srctree)/scripts/gcc-x86_64-has-stack-protector.sh $(1))
> cflags-$(CONFIG_CC_STACKPROTECTOR) += \
> $(call stack-protector, $(CC) -fstack-protector)
> cflags-$(CONFIG_CC_STACKPROTECTOR_ALL) += \
> $(call stack-protector, $(CC)
> -fstack-protector-all)
ok that works (I've tested it ;)
Subject: [patch 5/5] Add the -fstack-protector option to the CFLAGS
From: Arjan van de Ven <[email protected]>
Add a feature check that checks that the gcc compiler has stack-protector
support and has the bugfix for PR28281 to make this work in kernel mode.
The easiest solution I could find was to have a shell script in scripts/
to do the detection; if needed we can make this fancier in the future
without making the makefile too complex.
Signed-off-by: Arjan van de Ven <[email protected]>
CC: Andi Kleen <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
---
arch/x86_64/Makefile | 3 +++
scripts/gcc-x86_64-has-stack-protector.sh | 8 ++++++++
2 files changed, 11 insertions(+)
Index: linux-2.6.18-rc4-stackprot/arch/x86_64/Makefile
===================================================================
--- linux-2.6.18-rc4-stackprot.orig/arch/x86_64/Makefile
+++ linux-2.6.18-rc4-stackprot/arch/x86_64/Makefile
@@ -55,6 +55,15 @@ cflags-y += $(call cc-option,-funit-at-a
# prevent gcc from generating any FP code by mistake
cflags-y += $(call cc-option,-mno-sse -mno-mmx -mno-sse2 -mno-3dnow,)
+
+stack-protector = $(shell $(CONFIG_SHELL) \
+ $(srctree)/scripts/gcc-x86_64-has-stack-protector.sh $(1))
+
+cflags-$(CONFIG_CC_STACKPROTECTOR) += \
+ $(call stack-protector, $(CC) -fstack-protector)
+cflags-$(CONFIG_CC_STACKPROTECTOR_ALL) += \
+ $(call stack-protector, $(CC) -fstack-protector-all)
+
CFLAGS += $(cflags-y)
CFLAGS_KERNEL += $(cflags-kernel-y)
AFLAGS += -m64
Index: linux-2.6.18-rc4-stackprot/scripts/gcc-x86_64-has-stack-protector.sh
===================================================================
--- /dev/null
+++ linux-2.6.18-rc4-stackprot/scripts/gcc-x86_64-has-stack-protector.sh
@@ -0,0 +1,6 @@
+#!/bin/sh
+
+echo "int foo(void) { char X[200]; return 3; }" | $1 -S -xc -c -O0 -mcmodel=kernel -fstack-protector - -o - | grep -q "%gs"
+if [ "$?" -eq "0" ] ; then
+ echo $2
+fi
On Wednesday 16 August 2006 18:50, Arjan van de Ven wrote:
> Subject: [patch 2/5] Add the Kconfig option for the stackprotector feature
> From: Arjan van de Ven <[email protected]>
>
> This patch adds the config options for -fstack-protector.
Normally it's better to add the CONFIG options after the code or
at the same time. Otherwise binary searches later can break
Also can the CC be dropped in the option? It makes it too long.
-Andi
>
On Wednesday 16 August 2006 18:48, Arjan van de Ven wrote:
> This patch series adds support for the gcc -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. (For those who want to know more, see gcc
> PR 28281)
FWIW -- my queue for 2.6.19 is already quite full and I'm
in the stabilization phase for the merge.
I will merge these patches post the 2.6.19 merge window into
my tree for .20.
-Andi
On Fri, 2006-08-18 at 13:08 +0200, Andi Kleen wrote:
> On Wednesday 16 August 2006 18:50, Arjan van de Ven wrote:
> > Subject: [patch 2/5] Add the Kconfig option for the stackprotector feature
> > From: Arjan van de Ven <[email protected]>
> >
> > This patch adds the config options for -fstack-protector.
>
> Normally it's better to add the CONFIG options after the code or
> at the same time. Otherwise binary searches later can break
the binary search argument in this case is moot, just having a config
option doesn't break anything compile wise and each later step is
self-compiling..
On Fri, 2006-08-18 at 13:15 +0200, Andi Kleen wrote:
> On Wednesday 16 August 2006 18:48, Arjan van de Ven wrote:
> > This patch series adds support for the gcc -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. (For those who want to know more, see gcc
> > PR 28281)
>
> FWIW -- my queue for 2.6.19 is already quite full and I'm
> in the stabilization phase for the merge.
Andrew, can you please consider sticking these into -mm ?
FC6 already has a gcc capable of using this feature (and I hope/assume
other similar distros as well; for other distros using gcc 4.1, the
respective gcc owner should put in
http://www.fenrus.org/stackprotector/gcc41.patch to fix PR28281) and
since it's a relatively simple feature patch wise (and entirely off if
the config option is off) I sort of feel 2.6.20 is a long way away..
> the binary search argument in this case is moot, just having a config
> option doesn't break anything compile wise and each later step is
> self-compiling..
Not true when the config used for the binary search has stack protector
enabled.
-Andi
Andi Kleen wrote:
>> the binary search argument in this case is moot, just having a config
>> option doesn't break anything compile wise and each later step is
>> self-compiling..
>
> Not true when the config used for the binary search has stack protector
> enabled.
>
oh? I thought I was pretty careful about that
looking over the patches again I can't find any reason for a non-compiling/working kernel; at any step..
can you show me the compile error you got or the bug you found?
Also, I generally like this order since this order allows you to bisect stackprotector patches itself, rather than the
artificial "add a bunch of dead code and then suddenly turn the light on" approach..
On Fri, 2006-08-18 at 15:10 +0200, Arjan van de Ven wrote:
> Andi Kleen wrote:
> >> the binary search argument in this case is moot, just having a config
> >> option doesn't break anything compile wise and each later step is
> >> self-compiling..
> >
> > Not true when the config used for the binary search has stack protector
> > enabled.
> >
> oh? I thought I was pretty careful about that
>
> looking over the patches again I can't find any reason for a non-compiling/working kernel; at any step..
I just compiled each step separately [*] and they all compile just fine,
and will work just fine as well...
[*] <shameless plug>thanks to the 2 1/2 minute full kernel compile time
of my new Intel box with Woodcrest cpus </shameless plug>
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
On Fri, Aug 18, 2006 at 04:05:19PM +0200, Andi Kleen wrote:
>
> > the binary search argument in this case is moot, just having a config
> > option doesn't break anything compile wise and each later step is
> > self-compiling..
>
> Not true when the config used for the binary search has stack protector
> enabled.
kconfig will remove undefined CONFIG_ options from the .config as part
of the kernel compile.
Sam