Received: by 10.213.65.68 with SMTP id h4csp2356131imn; Mon, 9 Apr 2018 02:01:46 -0700 (PDT) X-Google-Smtp-Source: AIpwx48Q5m5RqhEzLFnr2ToGe2As8BzkBIcGu58mwhpyqeBjArRTjUXsp6bXdywaNKu9ICv9Rp1V X-Received: by 10.98.8.133 with SMTP id 5mr28215732pfi.154.1523264506610; Mon, 09 Apr 2018 02:01:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523264506; cv=none; d=google.com; s=arc-20160816; b=qc7OjnHZ5/GeuJduT1UBNv8DHQYZ+UNX6G33470Vftf2++uRMWdoDy1GA0wPQndQKt fLQtnR0dsCJZ2oHU/FP3og+dxvxeTyv1O5m3LYexjKYZiNY6GIJ10VklYBGtnqm0bvJu rVzFATw2/a7aRk2+4KFV7Z+NOuJehd/UAbpzW9brOBbOsf7wnLtydd+AL/qU+edKq7Gp 3P6sUWZ9K6JRrMQez6ucd836LB+4ecp5WkV1QXgI8oQduPr026wlc+dYngZjIAGJkipE K3ZezIkMxc9HVlIfm1y8HFu1F1w4aASdAWDdECnVHmGh3chOXdDJcCo2AwhNMXY12MX9 uhiA== 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=QSvGDfx7rVJHqtZDBG2Z05AGbymmtFRoba71vWrC76I=; b=UWhi+P9LfXMs8dMIVDBLWTcvugsqrrgLaw2opTFrElN0/a6z4DAJSnB7iwrSaKfLQZ 9Q9yUFR7M9JjOMUgsyyGEdN5S4vNRAP3DAGYw9lnk7H5XiR8dSA8YfPl2ntwH3P4WtgH NjelWY1Q1jFXp4Ustew8f9ZscbWHcofgrVNfhjnZ8IlQ2QZuLzjIfDOFmDZBB09z/Msz viQ2XJAeowaSwfSHAkBgyIERsd/QHV07BmucA4A929dhaA6j53XGwlD6h0stsvCvw7eX KCeB07eXcHZivwuQqqXOiunpeWnnFOUMMwheNKoyDyhqwy7pV4f9qBZq96nt+SlAKAWe fGCA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=cnuHqW1z; 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 y7-v6si14071611plh.583.2018.04.09.02.01.08; Mon, 09 Apr 2018 02:01:46 -0700 (PDT) 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=cnuHqW1z; 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 S1751737AbeDIIzW (ORCPT + 99 others); Mon, 9 Apr 2018 04:55:22 -0400 Received: from conssluserg-02.nifty.com ([210.131.2.81]:29853 "EHLO conssluserg-02.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751441AbeDIIzU (ORCPT ); Mon, 9 Apr 2018 04:55:20 -0400 Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com [209.85.213.44]) (authenticated) by conssluserg-02.nifty.com with ESMTP id w398tC7E001528; Mon, 9 Apr 2018 17:55:12 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-02.nifty.com w398tC7E001528 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1523264113; bh=QSvGDfx7rVJHqtZDBG2Z05AGbymmtFRoba71vWrC76I=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=cnuHqW1zOXzwSjVq09Gki4k4bgAnwBRJCYFKVzj/VZltq8fQjx/6gcIYdhC0NjVbJ Lk3wD9Kr77omdFR5ptZpebJuommESbMokDLPbV0jft/Zy4mj6nPXtHYwK8on0RXcJu UVDnhv99Hfp+hltvIOUnCX3zDgie2O/cpv2A8VHXXZnZjOZRCcSPiGNlkXpTk9FvQu I8rgbFX/3t6jX7NJGRHE1w8kBRhb3KJIS49Xj9X8Pl13Z5qCmUFEzrv/qg+UDVsSRa gdMkvgo+FrRpECSj67uwNKUsot/9WuyGApTWSS2fkwNeE2uZzARCK8c+QxyER49J0a L1tA+o+ScFUMg== X-Nifty-SrcIP: [209.85.213.44] Received: by mail-vk0-f44.google.com with SMTP id b16so4275009vka.5; Mon, 09 Apr 2018 01:55:12 -0700 (PDT) X-Gm-Message-State: ALQs6tBcnGsCyE171UsYf0k4w0kM5cmaJSSNeU4IkdR7JUXnQJOpziGk dXTYLev7GkOfNUelbpX9VGnNPDWNml7sny+oM6Y= X-Received: by 10.31.169.5 with SMTP id s5mr23810370vke.54.1523264111492; Mon, 09 Apr 2018 01:55:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.29.150 with HTTP; Mon, 9 Apr 2018 01:54:31 -0700 (PDT) In-Reply-To: References: <1522128575-5326-1-git-send-email-yamada.masahiro@socionext.com> <1522128575-5326-12-git-send-email-yamada.masahiro@socionext.com> From: Masahiro Yamada Date: Mon, 9 Apr 2018 17:54:31 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 11/21] stack-protector: test compiler capability in Kconfig and drop AUTO mode To: Kees Cook Cc: linux-kbuild , Sam Ravnborg , Linus Torvalds , Arnd Bergmann , Ulf Magnusson , Thomas Gleixner , Greg Kroah-Hartman , Randy Dunlap , "Luis R . Rodriguez" , Nicolas Pitre , LKML , 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-03-28 20:18 GMT+09:00 Kees Cook : > On Mon, Mar 26, 2018 at 10:29 PM, Masahiro Yamada > wrote: >> Move the test for -fstack-protector(-strong) option to Kconfig. >> >> If the compiler does not support the option, the corresponding menu >> is automatically hidden. If _STRONG is not supported, it will fall >> back to _REGULAR. If _REGULAR is not supported, it will be disabled. >> This means, _AUTO is implicitly handled by 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. >> >> 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. >> >> Signed-off-by: Masahiro Yamada > > This looks really good. Notes below... > >> --- >> >> Changes in v2: >> - Describe $(cc-option ...) directly in depends on context >> >> Makefile | 93 ++----------------------------- >> arch/Kconfig | 29 +++------- >> 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, 22 insertions(+), 120 deletions(-) >> >> diff --git a/Makefile b/Makefile >> index 5c395ed..5cadffa 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). > > Let's keep this comment (slightly rewritten) since the reason for > setting this flag isn't obvious. Will move this to help of arch/x86/Kconfig >> - KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector) >> - endif >> -endif >> -endif >> +stackp-flags-y := -fno-stack-protector > > This is a (minor?) regression in my testing. Making this unconditional > may break for a compiler built without stack-protector. It should be > rare, but it's technically possible. Perhaps: > > stackp-flags-y := ($call cc-option, -fno-stack-protector) Will add CONFIG_CC_HAS_STACKPROTECTOR_NONE >> +stackp-flags-$(CONFIG_CC_STACKPROTECTOR) := -fstack-protector >> +stackp-flags-$(CONFIG_CC_STACKPROTECTOR_STRONG) := -fstack-protector-strong >> + >> +KBUILD_CFLAGS += $(stackp-flags-y) >> [...] >> diff --git a/arch/Kconfig b/arch/Kconfig >> index 8e0d665..b42378d 100644 >> --- a/arch/Kconfig >> +++ b/arch/Kconfig >> @@ -535,13 +535,13 @@ config HAVE_CC_STACKPROTECTOR >> bool >> help >> An arch should select this symbol if: >> - - its compiler supports the -fstack-protector option > > Please leave this note: it's still valid. An arch must still have > compiler support for this to be sensible. > No. "its compiler supports the -fstack-protector option" is tested by $(cc-option -fstack-protector) ARCH does not need to know the GCC support level. >> - it has implemented a stack canary (e.g. __stack_chk_guard) -- Best Regards Masahiro Yamada