From: Kees Cook Date: Wed, 6 Aug 2014 23:03:31 +0000 (-0700) Subject: ./Makefile: explain stack-protector-strong CONFIG logic X-Git-Tag: v3.17-rc1~94^2~221 X-Git-Url: https://openfabrics.org/gitweb/?a=commitdiff_plain;h=1332429b305044aa75163399ae960c6535828ce6;p=~emulex%2Finfiniband.git ./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 --- diff --git a/Makefile b/Makefile index d0901b46b4b..af2f2fcfe01 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)),)