From 1332429b305044aa75163399ae960c6535828ce6 Mon Sep 17 00:00:00 2001 From: Kees Cook Date: Wed, 6 Aug 2014 16:03:31 -0700 Subject: [PATCH] ./Makefile: explain stack-protector-strong CONFIG logic This adds a hopefully helpful comment above the (seemingly weird) compiler flag selection logic. Signed-off-by: Kees Cook Suggested-by: Andrew Morton Cc: Andi Kleen Cc: Randy Dunlap Cc: Michal Marek Cc: Michal Hocko Cc: Stephen Rothwell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Makefile | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/Makefile b/Makefile index d0901b46b4bf..af2f2fcfe01c 100644 --- a/Makefile +++ b/Makefile @@ -636,6 +636,22 @@ KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN}) endif # Handle stack protector mode. +# +# Since kbuild can potentially perform two passes (first with the old +# .config values and then with updated .config values), we cannot error out +# if a desired compiler option is unsupported. If we were to error, kbuild +# could never get to the second pass and actually notice that we changed +# the option to something that was supported. +# +# Additionally, we don't want to fallback and/or silently change which compiler +# flags will be used, since that leads to producing kernels with different +# security feature characteristics depending on the compiler used. ("But I +# selected CC_STACKPROTECTOR_STRONG! Why did it build with _REGULAR?!") +# +# The middle ground is to warn here so that the failed option is obvious, but +# to let the build fail with bad compiler flags so that we can't produce a +# kernel when there is a CONFIG and compiler mismatch. +# ifdef CONFIG_CC_STACKPROTECTOR_REGULAR stackp-flag := -fstack-protector ifeq ($(call cc-option, $(stackp-flag)),) -- GitLab