From patchwork Thu Jul 3 01:10:59 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kees Cook X-Patchwork-Id: 4468721 Return-Path: X-Original-To: patchwork-linux-kbuild@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 558169F26C for ; Thu, 3 Jul 2014 01:12:25 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 52706203AE for ; Thu, 3 Jul 2014 01:12:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5087F203AA for ; Thu, 3 Jul 2014 01:12:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751344AbaGCBMG (ORCPT ); Wed, 2 Jul 2014 21:12:06 -0400 Received: from smtp.outflux.net ([198.145.64.163]:57555 "EHLO smtp.outflux.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750809AbaGCBMF (ORCPT ); Wed, 2 Jul 2014 21:12:05 -0400 Received: from www.outflux.net (serenity.outflux.net [10.2.0.2]) by vinyl.outflux.net (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id s631B0Hb032767; Wed, 2 Jul 2014 18:11:08 -0700 Date: Wed, 2 Jul 2014 18:10:59 -0700 From: Kees Cook To: Andrew Morton Cc: Andi Kleen , Randy Dunlap , linux-next@vger.kernel.org, sfr@canb.auug.org.au, mhocko@suse.cz, linux-kernel@vger.kernel.org, Michal Marek , linux-kbuild@vger.kernel.org Subject: [PATCH] kbuild: explain stack-protector-strong CONFIG logic Message-ID: <20140703011059.GA6331@www.outflux.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20140702175635.79d54c44.akpm@linux-foundation.org> X-MIMEDefang-Filter: outflux$Revision: 1.316 $ X-HELO: www.outflux.net X-Scanned-By: MIMEDefang 2.73 Sender: linux-kbuild-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kbuild@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP This adds a hopefully helpful comment above the (seemingly weird) compiler flag selection logic. Suggested-by: Andrew Morton Signed-off-by: Kees Cook --- Makefile | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/Makefile b/Makefile index 13175632137f..ea88e68d121e 100644 --- a/Makefile +++ b/Makefile @@ -630,6 +630,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)),)