Received: by 10.192.165.156 with SMTP id m28csp988899imm; Fri, 13 Apr 2018 11:14:34 -0700 (PDT) X-Google-Smtp-Source: AIpwx49of1CFpCah/FIc0Rs3muhbhuemrmbQulhRyMHmw5L8xu6dC839U1EFnsPmccln/jb7Qwu2 X-Received: by 2002:a17:902:128c:: with SMTP id g12-v6mr5960310pla.98.1523643274937; Fri, 13 Apr 2018 11:14:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523643274; cv=none; d=google.com; s=arc-20160816; b=JYPP83wQd2RH5EJJyokcCLyGJYswW3DxOjOKXZkBIUFf/OgtKBW3GmN9n0ULyG0Ryy TxIqui0Zonp3RxxxxgTggocPf3HCDreh7NSI0n5tkleWyfTPdphUNIg+trbxXpes5DBr /858eeN4nJUhurDrzazeMrw16X1edipFACNCeYWaNXnj4VwrGt30A/Zkhdhd2o2lCO0p M7MDFQFcegSjIuVF5jsshqEsz1RnnvXOX18d1Vq2DrrmRli0pfPKvp9DVqypkRhBcwcl Pj6w7xATS4n5ALKYccPEJPgE4nnXmPmNLY96R+rXsi/daw+evWy7UoKRbI/de3jnK3Lz h2Fg== 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-signature :arc-authentication-results; bh=IzwztuNHdqYPLJcst/ZnoNP1CMvBCW27d40MXUImR3A=; b=HE4gG5IRsJfRAEx9wLnG1GHqkHbsyZD7CQnljcsEw8JC5zxbBmM/hpFun4owLRoRk7 0BI0Vr5JjjsK5ztyGzb+x0XmJ/aOh2mpwJFPc8I5xX0JZ41EkvgB0EhKNS1nPlpGSjHM TiN6ZIq4V31LJVRcFDCWwZioAth39IslZoD8Mix8n1bp7tUjfyiQFC36oJqmAdENye7C xpkMNmaaE0w/YsFOXbjSI4KuprzrogFXyuaY6x6V/dhkz08Qpfml+Dht/NbJStVhqzgW 8sWVT719W06MGgLxwhd1MFMBcyEQm4+54TLCfDmzN2qB/Ruy8wvtg4S2dnXWUxO4KtPI lZCw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=ug9/tCq4; dkim=fail header.i=@linux-foundation.org header.s=google header.b=Ipud7zDs; 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 bb10-v6si5857713plb.472.2018.04.13.11.14.20; Fri, 13 Apr 2018 11:14:34 -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=fail header.i=@gmail.com header.s=20161025 header.b=ug9/tCq4; dkim=fail header.i=@linux-foundation.org header.s=google header.b=Ipud7zDs; 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 S1751024AbeDMSMA (ORCPT + 99 others); Fri, 13 Apr 2018 14:12:00 -0400 Received: from mail-it0-f51.google.com ([209.85.214.51]:52949 "EHLO mail-it0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750832AbeDMSL6 (ORCPT ); Fri, 13 Apr 2018 14:11:58 -0400 Received: by mail-it0-f51.google.com with SMTP id f6-v6so4289801ita.2; Fri, 13 Apr 2018 11:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=IzwztuNHdqYPLJcst/ZnoNP1CMvBCW27d40MXUImR3A=; b=ug9/tCq4q4Pj6oSFiO1VGn3PpD5ZPSQnm6e5vTDnjEDiDHa/4sb4jyKWJ6JG//mUJy jvXL/KK3oHcBjwQWaYMD5VELYbbah5K4q9mSpmWlbIsmsjdwiGHYnOyyZ6um6U4p2qcb +2RrqXXCCg/wNKi5C81vXkFHKJ3HRZGwtxX4VDwxAYikCOVqGPjyslda6Cs8fnmv4y6F 68UjeftXYfLtopOBabLzzn4fca/CecABChqa+xkbi/mEFJuqA119uFeVJtJa4EESYixB +obXehV4v5Yif73baNdQcnGewcDjhJJVpG1LPYNKo5I6qRu1nqR2n8yF1CSBdEjbzh1P pCXw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=IzwztuNHdqYPLJcst/ZnoNP1CMvBCW27d40MXUImR3A=; b=Ipud7zDsrO7f9MqB4OzHpedDseVmhvY0FiegOtu6tZeIoQHeBuODQihqc9U2wcyGCA rCysnpyhUCjpx5X1NUbxn1bJzqjiKVWJOJABXn4aQzDZ27Xo280sJkP0OlngCFJ8tahy EZUyGjJzKfNmXAGNGaOO3P2UGg5J41jZAbM2k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=IzwztuNHdqYPLJcst/ZnoNP1CMvBCW27d40MXUImR3A=; b=TJp8xokm19adWa6oKi6vq0zqABfO5UYRJOu//UvIeXImSE/1EMmI7XZ9RwSFHSNPC+ bQ+hE6i3XluasIZYy2HYT9wkwzOMNede2k9Dq/yw7d0NJuOf8nQk0NkaYcxx+AQ3kXzd skFc1tnBAg7FAzZv8rjc6yD+mpGR3+rHhawCF8QNWwWcnbWAxMC303HW0egLPwrWt3s4 wq6qsfMmu/CnFqPb2BdPVGkzXMjtDnUOniBGKvdUs9H4TaVWQ+/BjMslrNOWqs6KvMJi cN2SzyMApASIm4eOc1nSjwfbUz0FI9eNyt7qHg6E8jkGDJytjo9nFAiBnBLiEOblnMu9 PwNA== X-Gm-Message-State: ALQs6tDx1goFM3PqhQ/gOFBIGv+lXwSkgi5Yz26SowH4REPcECKj7/Bu G7m10hjdqhKbCKtXuOUi2Uh5cFzj/+kEyYsmyOM= X-Received: by 2002:a24:5b02:: with SMTP id g2-v6mr6588770itb.100.1523643117164; Fri, 13 Apr 2018 11:11:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.95.15 with HTTP; Fri, 13 Apr 2018 11:11:56 -0700 (PDT) In-Reply-To: References: <1523595999-27433-1-git-send-email-yamada.masahiro@socionext.com> <1523595999-27433-22-git-send-email-yamada.masahiro@socionext.com> From: Linus Torvalds Date: Fri, 13 Apr 2018 11:11:56 -0700 X-Google-Sender-Auth: GGiVu5v8GwyAr8hUyJLe1fT6dNI Message-ID: Subject: Re: [PATCH 21/30] stack-protector: test compiler capability in Kconfig and drop AUTO mode To: Kees Cook Cc: Masahiro Yamada , linux-kbuild , Sam Ravnborg , Ulf Magnusson , Nicholas Piggin , Emese Revfy , X86 ML , LKML 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 On Fri, Apr 13, 2018 at 9:41 AM, Kees Cook wrote: > > How about something like this instead: I'd rather avoid the ifdef's in the Makefile if at all possible. I'd rather expose this as a Kconfig rule, and in the Kconfig just have an entry something like this config STACKPROTECTOR_FLAGS string default "-fstack-protector-strong" if CC_STACKPROTECTOR_STRONG default "-fstack-protector" if CC_STACKPROTECTOR default "-fno-stack-protector" if CC_HAS_STACKPROTECTOR_NONE default "" which is really simple and straightforward. In the presense of multiple defaults, the first is picked, so this _automatically_ does that whole priority ordering. And then the Makefile can just have KBUILD_CFLAGS += $(CONFIG_STACKPROTECTOR_FLAGS) which seems much simpler. It also makes more complex conditionals easier (ie different compilers with different flags, since clang sometimes does the same thing with another flag name), so I'd rather see this pattern in general. I'd also *much* rather do as much as possible at Kconfig time compared to build time. Maybe it's just shifting the costs around, but the less "clever" things we ask "make" to do, the better. I find our Makefiles an odd combination of really clean and simply (the ones that just have "obj-$(CONFIG_X) += xyz.o" are just lovely) and completely incomprehensible (all of our infrastructure support for the simple stuff). I'd rather have more of the simple stuff in Makefiles, less of the complex conditionals. Linus