Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables (050e9baa) · Commits · 戴 / test

The changes to automatically test for working stack protector compiler support in the Kconfig files removed the special STACKPROTECTOR_AUTO option that picked the strongest stack protector that the compiler supported. That was all a nice cleanup - it makes no sense to have the AUTO case now that the Kconfig phase can just determine the compiler support directly. HOWEVER. It also meant that doing "make oldconfig" would now _disable_ the strong stackprotector if you had AUTO enabled, because in a legacy config file, the sane stack protector configuration would look like CONFIG_HAVE_CC_STACKPROTECTOR=y # CONFIG_CC_STACKPROTECTOR_NONE is not set # CONFIG_CC_STACKPROTECTOR_REGULAR is not set # CONFIG_CC_STACKPROTECTOR_STRONG is not set CONFIG_CC_STACKPROTECTOR_AUTO=y and when you ran this through "make oldconfig" with the Kbuild changes, it would ask you about the regular CONFIG_CC_STACKPROTECTOR (that had been renamed from CONFIG_CC_STACKPROTECTOR_REGULAR to just CONFIG_CC_STACKPROTECTOR), but it would think that the STRONG version used to be disabled (because it was really enabled by AUTO), and would disable it in the new config, resulting in: CONFIG_HAVE_CC_STACKPROTECTOR=y CONFIG_CC_HAS_STACKPROTECTOR_NONE=y CONFIG_CC_STACKPROTECTOR=y # CONFIG_CC_STACKPROTECTOR_STRONG is not set CONFIG_CC_HAS_SANE_STACKPROTECTOR=y That's dangerously subtle - people could suddenly find themselves with the weaker stack protector setup without even realizing. The solution here is to just rename not just the old RECULAR stack protector option, but also the strong one. This does that by just removing the CC_ prefix entirely for the user choices, because it really is not about the compiler support (the compiler support now instead automatially impacts _visibility_ of the options to users). This results in "make oldconfig" actually asking the user for their choice, so that we don't have any silent subtle security model changes. The end result would generally look like this: CONFIG_HAVE_CC_STACKPROTECTOR=y CONFIG_CC_HAS_STACKPROTECTOR_NONE=y CONFIG_STACKPROTECTOR=y CONFIG_STACKPROTECTOR_STRONG=y CONFIG_CC_HAS_SANE_STACKPROTECTOR=y where the "CC_" versions really are about internal compiler infrastructure, not the user selections. Acked-by:

Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:

Linus Torvalds <torvalds@linux-foundation.org>

Documentation/kbuild/kconfig-language.txt

+1 −1

Original line number	Diff line number	Diff line
		@@ -480,7 +480,7 @@ There are several features that need compiler support. The recommended way
		to describe the dependency on the compiler feature is to use "depends on"
		followed by a test macro.

		config CC_STACKPROTECTOR
		config STACKPROTECTOR
		bool "Stack Protector buffer overflow detection"
		depends on $(cc-option,-fstack-protector)
		...

Documentation/security/self-protection.rst

+1 −1

Original line number	Diff line number	Diff line
		@@ -156,7 +156,7 @@ The classic stack buffer overflow involves writing past the expected end
		of a variable stored on the stack, ultimately writing a controlled value
		to the stack frame's stored return address. The most widely used defense
		is the presence of a stack canary between the stack variables and the
		return address (``CONFIG_CC_STACKPROTECTOR``), which is verified just before
		return address (``CONFIG_STACKPROTECTOR``), which is verified just before
		the function returns. Other defenses include things like shadow stacks.

		Stack depth overflow

Makefile

+2 −2

Original line number	Diff line number	Diff line
		@@ -687,8 +687,8 @@ KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})
		endif

		stackp-flags-$(CONFIG_CC_HAS_STACKPROTECTOR_NONE) := -fno-stack-protector
		stackp-flags-$(CONFIG_CC_STACKPROTECTOR) := -fstack-protector
		stackp-flags-$(CONFIG_CC_STACKPROTECTOR_STRONG) := -fstack-protector-strong
		stackp-flags-$(CONFIG_STACKPROTECTOR) := -fstack-protector
		stackp-flags-$(CONFIG_STACKPROTECTOR_STRONG) := -fstack-protector-strong

		KBUILD_CFLAGS += $(stackp-flags-y)

arch/Kconfig

+3 −3

Original line number	Diff line number	Diff line
		@@ -558,7 +558,7 @@ config HAVE_CC_STACKPROTECTOR
		config CC_HAS_STACKPROTECTOR_NONE
		def_bool $(cc-option,-fno-stack-protector)

		config CC_STACKPROTECTOR
		config STACKPROTECTOR
		bool "Stack Protector buffer overflow detection"
		depends on HAVE_CC_STACKPROTECTOR
		depends on $(cc-option,-fstack-protector)
		@@ -582,9 +582,9 @@ config CC_STACKPROTECTOR
		about 3% of all kernel functions, which increases kernel code size
		by about 0.3%.

		config CC_STACKPROTECTOR_STRONG
		config STACKPROTECTOR_STRONG
		bool "Strong Stack Protector"
		depends on CC_STACKPROTECTOR
		depends on STACKPROTECTOR
		depends on $(cc-option,-fstack-protector-strong)
		default y
		help

arch/arm/kernel/asm-offsets.c

+1 −1

Original line number	Diff line number	Diff line
		@@ -61,7 +61,7 @@
		int main(void)
		{
		DEFINE(TSK_ACTIVE_MM, offsetof(struct task_struct, active_mm));
		#ifdef CONFIG_CC_STACKPROTECTOR
		#ifdef CONFIG_STACKPROTECTOR
		DEFINE(TSK_STACK_CANARY, offsetof(struct task_struct, stack_canary));
		#endif
		BLANK();

Admin message