linux-kernel - Re: Stack protector build failure (was Re: 2.6.25-mm1: not looking good)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4808D2F2.7030008@linux.intel.com>
Date:	Fri, 18 Apr 2008 09:57:22 -0700
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	Arjan van de Ven <arjan@...radead.org>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>, sam@...nborg.org,
	linux-kernel@...r.kernel.org
Subject: Re: Stack protector build failure (was Re: 2.6.25-mm1: not looking
 good)

Arjan van de Ven wrote:
> On Fri, 18 Apr 2008 00:28:58 -0700
> Andrew Morton <akpm@...ux-foundation.org> wrote:
> 
> 
>>> No harm done on a 
>>> perfectly bug-free system - but once a bug happens that SELinux
>>> should have mitigated, the breakage becomes real. Having a
>>> prominent warning is the _minimum_.
>>>
>>> having a build failure would be nice too because this is a build 
>>> environment problem. (not a build warning - warnings can easily be 
>>> missed because on a typical kernel build there's so many false
>>> positives that get emitted by various other warning mechanisms)
>>> Arjan?
>>>
>> Yeah, #error would work too.
> 
> I'm totally fine with that, but I think I need Sam's help on making that happen
> the right way; this is going to need makefile fu L(
> 

ok I found a way that works for me:

From: Arjan van de Ven <arjan@...ux.intel.com>
Subject: [PATCH] stackprotector: turn not having the right gcc into an #error

If the user selects the stack-protector config option, but does not have
a gcc that has the right bits enabled (for example because it isn't build
with a glibc that supports TLS, as is common for cross-compilers, but also
because it may be too old), then the runtime test fails right now.

Andrew rightfully points out that this is a condition we can detect at
build time, and we should error out at that point instead.

This patch adds an error message for this scenario. This error accomplishes
two goals
1) the user is informed that the security option he selective isn't available
2) the user has enough info to turn of the CONFIG option that won't work for him,
    and would make the runtime test fail anyway.

Signed-off-by: Arjan van de Ven <arjan@...ux.intel.com>
---
  arch/x86/Makefile |    2 +-
  kernel/panic.c    |    3 +++
  2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 3cff3c8..c3e0eee 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -73,7 +73,7 @@ else

          stackp := $(CONFIG_SHELL) $(srctree)/scripts/gcc-x86_64-has-stack-protector.sh
          stackp-$(CONFIG_CC_STACKPROTECTOR) := $(shell $(stackp) \
-                "$(CC)" -fstack-protector )
+                "$(CC)" "-fstack-protector -DGCC_HAS_SP" )
          stackp-$(CONFIG_CC_STACKPROTECTOR_ALL) += $(shell $(stackp) \
                  "$(CC)" -fstack-protector-all )

diff --git a/kernel/panic.c b/kernel/panic.c
index c92c1e2..7cbcd8e 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -321,6 +321,9 @@ EXPORT_SYMBOL(warn_on_slowpath);

  #ifdef CONFIG_CC_STACKPROTECTOR

+#ifndef GCC_HAS_SP
+#error You have selected the CONFIG_CC_STACKPROTECTOR option, but the gcc used does not support this.
+#endif
  static unsigned long __stack_check_testing;
  /*
   * Self test function for the stack-protector feature.
-- 
1.5.4.5


View attachment "0001-stackprotector-turn-not-having-the-right-gcc-into-a.patch" of type "text/x-patch" (2112 bytes)