Received: by 10.223.185.116 with SMTP id b49csp258388wrg; Tue, 20 Feb 2018 20:42:25 -0800 (PST) X-Google-Smtp-Source: AH8x224izW+5FJNwSOk+daU0Adfl4zTxOTZMVIWfYbBc47FwjjHDeP3QwRQHiX0LuwtdEKX/Ootu X-Received: by 10.98.30.67 with SMTP id e64mr1992628pfe.111.1519188144984; Tue, 20 Feb 2018 20:42:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519188144; cv=none; d=google.com; s=arc-20160816; b=PbUiBreC7tQHRlDwIwfbJCzCtZWPyQmHfQ243WeAyRRD5mmQl9L4wZq88C/iMgWG7x wmv8Zi+r5Aaxcl9GJa++Fr9g4kWaSv5bJeQiswzTd/omtXQPpvCWKYilUno8a743NLD4 unuDcIl4g1EgQcFCoxP6lndAis4KYusidCY9MmgE6lwpON9CVFx/vAWwbUqmB232DfOH V/8VQBNRJH+vn/f7P+gDB+alLFpiaPKXJfnsXRN2BdKD0i6GBdwcj0hc750Z1wY+IzIO J8TSfuzSEaM+Uv38CtAE5JNRoxsXrPvZk9ZvZ1RtfmrFqWS8E60Yd2etJpE+xpaYzRcS umdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature:dkim-filter :arc-authentication-results; bh=GSzLjT9gc8TQGGW01vUxEYZ9vtVJdz8/goTqBurh0MM=; b=z10lnEpuz2Xh3JLnq95DHkAeHCoQ6h3GJ9MUXKRqEquH/aZZoCN5HWZOgAIh/vPNGL y2eCmjN/2wGGlurEuipNL02/Z34e3+T6F/b2TyOA5/+8uuAz9Et1YoBEYsbRHBJhJsi7 +s8iD79jTNIbCWkhf/lH4bXYjLk4hxhwtSCuxFC5SuYMWce0rFYeysEp+uWIsNIInJUt 03dVdljh9lKrQAXVTmsARXRpZiFG0kF8DK5ebJWKWvzlwul4WWS5JRBhY4fiUJz53uQS eNuh60ZTaPqsVRD29zzT889s4JnItuDLfrsnpDmmdRP9idpXi0edRq+TuwGahdgtNGnL WcKw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=Q6piW+OO; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g9si5769402pgn.813.2018.02.20.20.42.10; Tue, 20 Feb 2018 20:42:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=Q6piW+OO; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751383AbeBUEku (ORCPT + 99 others); Tue, 20 Feb 2018 23:40:50 -0500 Received: from conssluserg-05.nifty.com ([210.131.2.90]:20598 "EHLO conssluserg-05.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751135AbeBUEks (ORCPT ); Tue, 20 Feb 2018 23:40:48 -0500 Received: from mail-ua0-f169.google.com (mail-ua0-f169.google.com [209.85.217.169]) (authenticated) by conssluserg-05.nifty.com with ESMTP id w1L4eYiH011723; Wed, 21 Feb 2018 13:40:34 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-05.nifty.com w1L4eYiH011723 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1519188035; bh=GSzLjT9gc8TQGGW01vUxEYZ9vtVJdz8/goTqBurh0MM=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=Q6piW+OO4SeXNBSWytfgmeDbSqrNxtGVBxFXnpdAfumyLoMJKRmYCcTp1H8mP3d17 TuO0BFh9G3z659Ry5ZQNS576k1Qt833OKIGEhhJjWQUdtqkj/2j5flRgNCC0CuQPdp 9YxIAwFBawX2iOQHj8akNPhP2BbSE2a50ocdyRA43uI0JlzEMqTsXnBEzfsRZbE753 UT+pt4+N3k1M4m6mX7lUCG8HIK1OFJhasVJKn/un4LycpjOugjnEhsgKpiDoNPIklb yGTJhtBeMNg7hxhs1in6qiF/GpMHjBXrG7ksTE3b3iXL3Gwn3FWvigmjfcyT1Fjapy HnMNHI82zrsyA== X-Nifty-SrcIP: [209.85.217.169] Received: by mail-ua0-f169.google.com with SMTP id u99so245814uau.8; Tue, 20 Feb 2018 20:40:34 -0800 (PST) X-Gm-Message-State: APf1xPB6pRoj271FitrkJKcuZ3Bo9A9B4mQbPUSRoN5W0niyOPgFdB4J jjdO2SH3oARRkq90GBc9AV95YhVdsSOemjcYlpk= X-Received: by 10.176.6.136 with SMTP id g8mr1563738uag.82.1519188033584; Tue, 20 Feb 2018 20:40:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.83.212 with HTTP; Tue, 20 Feb 2018 20:39:53 -0800 (PST) In-Reply-To: <1518806331-7101-11-git-send-email-yamada.masahiro@socionext.com> References: <1518806331-7101-1-git-send-email-yamada.masahiro@socionext.com> <1518806331-7101-11-git-send-email-yamada.masahiro@socionext.com> From: Masahiro Yamada Date: Wed, 21 Feb 2018 13:39:53 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 10/23] stack-protector: test compiler capability in Kconfig and drop AUTO mode To: Linux Kbuild mailing list , Linus Torvalds Cc: Greg Kroah-Hartman , Arnd Bergmann , Kees Cook , Randy Dunlap , Ulf Magnusson , Sam Ravnborg , Michal Marek , Masahiro Yamada , "H. Peter Anvin" , X86 ML , Linux Kernel Mailing List , Thomas Gleixner , Ingo Molnar Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2018-02-17 3:38 GMT+09:00 Masahiro Yamada : > Add CC_HAS_STACKPROTECTOR(_STRONG) to test if the compiler supports > -fstack-protector(-strong) option. > > X86 has additional shell scripts in case the compiler supports the > option, but generates broken code. I added CC_HAS_SANE_STACKPROTECTOR > to test this. I had to add -m32 to gcc-x86_32-has-stack-protector.sh > to make it work correctly. > > If the compiler does not support the option, the menu is automatically > hidden. If _STRONG is not supported, it will fall back to _REGULAR. > This means, _AUTO is implicitly supported in the dependency solver of > Kconfig, hence removed. > > I also turned the 'choice' into only two boolean symbols. The use of > 'choice' is not a good idea here, because all of all{yes,mod,no}config > would choose the first visible value, while we want allnoconfig to > disable as many features as possible. > > I did not add CC_HAS_STACKPROTECTOR_NONE in the hope that GCC versions > we support will recognize -fno-stack-protector. > > If this turns out to be a problem, it will be possible to do this: > > 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 > > Signed-off-by: Masahiro Yamada > --- > > Makefile | 93 ++----------------------------- > arch/Kconfig | 37 ++++++------ > arch/x86/Kconfig | 8 ++- > scripts/gcc-x86_32-has-stack-protector.sh | 7 +-- > scripts/gcc-x86_64-has-stack-protector.sh | 5 -- > 5 files changed, 30 insertions(+), 120 deletions(-) > > diff --git a/Makefile b/Makefile > index 9a8c689..e9fc7c9 100644 > --- a/Makefile > +++ b/Makefile > @@ -675,55 +675,11 @@ ifneq ($(CONFIG_FRAME_WARN),0) > KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN}) > endif > > -# This selects the stack protector compiler flag. Testing it is delayed > -# until after .config has been reprocessed, in the prepare-compiler-check > -# target. > -ifdef CONFIG_CC_STACKPROTECTOR_AUTO > - stackp-flag := $(call cc-option,-fstack-protector-strong,$(call cc-option,-fstack-protector)) > - stackp-name := AUTO > -else > -ifdef CONFIG_CC_STACKPROTECTOR_REGULAR > - stackp-flag := -fstack-protector > - stackp-name := REGULAR > -else > -ifdef CONFIG_CC_STACKPROTECTOR_STRONG > - stackp-flag := -fstack-protector-strong > - stackp-name := STRONG > -else > - # If either there is no stack protector for this architecture or > - # CONFIG_CC_STACKPROTECTOR_NONE is selected, we're done, and $(stackp-name) > - # is empty, skipping all remaining stack protector tests. > - # > - # Force off for distro compilers that enable stack protector by default. > - KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector) > -endif > -endif > -endif > -# Find arch-specific stack protector compiler sanity-checking script. > -ifdef stackp-name > -ifneq ($(stackp-flag),) > - stackp-path := $(srctree)/scripts/gcc-$(SRCARCH)_$(BITS)-has-stack-protector.sh > - stackp-check := $(wildcard $(stackp-path)) > - # If the wildcard test matches a test script, run it to check functionality. > - ifdef stackp-check > - ifneq ($(shell $(CONFIG_SHELL) $(stackp-check) $(CC) $(KBUILD_CPPFLAGS) $(biarch)),y) > - stackp-broken := y > - endif > - endif > - ifndef stackp-broken > - # If the stack protector is functional, enable code that depends on it. > - KBUILD_CPPFLAGS += -DCONFIG_CC_STACKPROTECTOR > - # Either we've already detected the flag (for AUTO) or we'll fail the > - # build in the prepare-compiler-check rule (for specific flag). > - KBUILD_CFLAGS += $(stackp-flag) > - else > - # We have to make sure stack protector is unconditionally disabled if > - # the compiler is broken (in case we're going to continue the build in > - # AUTO mode). > - KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector) > - endif > -endif > -endif > +stackp-flags-y := -fno-stack-protector > +stackp-flags-$(CONFIG_CC_STACKPROTECTOR) := -fstack-protector > +stackp-flags-$(CONFIG_CC_STACKPROTECTOR_STRONG) := -fstack-protector-strong > + > +KBUILD_CFLAGS += $(stackp-flags-y) > > ifeq ($(cc-name),clang) > KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,) > @@ -1079,7 +1035,7 @@ endif > # prepare2 creates a makefile if using a separate output directory. > # From this point forward, .config has been reprocessed, so any rules > # that need to depend on updated CONFIG_* values can be checked here. > -prepare2: prepare3 prepare-compiler-check outputmakefile asm-generic > +prepare2: prepare3 outputmakefile asm-generic > > prepare1: prepare2 $(version_h) include/generated/utsrelease.h \ > include/config/auto.conf > @@ -1105,43 +1061,6 @@ uapi-asm-generic: > PHONY += prepare-objtool > prepare-objtool: $(objtool_target) > > -# Check for CONFIG flags that require compiler support. Abort the build > -# after .config has been processed, but before the kernel build starts. > -# > -# For security-sensitive CONFIG options, 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. (For example, "But I selected > -# CC_STACKPROTECTOR_STRONG! Why did it build with _REGULAR?!") > -PHONY += prepare-compiler-check > -prepare-compiler-check: FORCE > -# Make sure compiler supports requested stack protector flag. > -ifdef stackp-name > - # Warn about CONFIG_CC_STACKPROTECTOR_AUTO having found no option. > - ifeq ($(stackp-flag),) > - @echo CONFIG_CC_STACKPROTECTOR_$(stackp-name): \ > - Compiler does not support any known stack-protector >&2 > - else > - # Fail if specifically requested stack protector is missing. > - ifeq ($(call cc-option, $(stackp-flag)),) > - @echo Cannot use CONFIG_CC_STACKPROTECTOR_$(stackp-name): \ > - $(stackp-flag) not supported by compiler >&2 && exit 1 > - endif > - endif > -endif > -# Make sure compiler does not have buggy stack-protector support. If a > -# specific stack-protector was requested, fail the build, otherwise warn. > -ifdef stackp-broken > - ifeq ($(stackp-name),AUTO) > - @echo CONFIG_CC_STACKPROTECTOR_$(stackp-name): \ > - $(stackp-flag) available but compiler is broken: disabling >&2 > - else > - @echo Cannot use CONFIG_CC_STACKPROTECTOR_$(stackp-name): \ > - $(stackp-flag) available but compiler is broken >&2 && exit 1 > - endif > -endif > - @: > - > # Generate some files > # --------------------------------------------------------------------------- > > diff --git a/arch/Kconfig b/arch/Kconfig > index 76c0b54..9b7a628 100644 > --- a/arch/Kconfig > +++ b/arch/Kconfig > @@ -535,13 +535,21 @@ config HAVE_CC_STACKPROTECTOR > bool > help > An arch should select this symbol if: > - - its compiler supports the -fstack-protector option > - it has implemented a stack canary (e.g. __stack_chk_guard) > > -choice > - prompt "Stack Protector buffer overflow detection" > +config CC_HAS_STACKPROTECTOR > + bool > + default $(cc-option -fstack-protector) > + > +config CC_HAS_STACKPROTECTOR_STRONG > + bool > + default $(cc-option -fstack-protector-strong) > + > +config CC_STACKPROTECTOR > + bool "Stack Protector buffer overflow detection" > depends on HAVE_CC_STACKPROTECTOR > - default CC_STACKPROTECTOR_AUTO > + depends on CC_HAS_STACKPROTECTOR > + default y > help CC_HAS_STACKPROTECTOR is not mandatory in this case because we can directly describe $(cc-option ...) in 'depends on' context, like this: config CC_STACKPROTECTOR bool "Stack Protector buffer overflow detection" depends on HAVE_CC_STACKPROTECTOR depends on $(cc-option -fstack-protector-strong) default y The difference is CONFIG_CC_HAS_STACKPROTECTOR will not be written into the .config file. Maybe, is this useful information? You can check .config in case "BTW, can my compiler support this flag?" I will keep CC_HAS_ symbols, but I am open to this item. -- Best Regards Masahiro Yamada