Received: by 10.223.185.116 with SMTP id b49csp482250wrg; Sat, 10 Feb 2018 11:25:03 -0800 (PST) X-Google-Smtp-Source: AH8x227gekNbN54ktQlJ8hs77dQNTldhVy1HRj67pSQuoUZ/D/kEIE6KwG63GAU8B8GKNbemLfhA X-Received: by 10.101.80.69 with SMTP id k5mr5598678pgo.435.1518290703749; Sat, 10 Feb 2018 11:25:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518290703; cv=none; d=google.com; s=arc-20160816; b=sGf4irgzy1CQPMllEa+GlUP77Hp2hLAeff9IE+l6Ugd/V2gtlZgXURBYuwjJ++pSUV VpYmtFLHtIcVZ9wXoJUxfMAF/e4pDTI3ggg3yBxGX5jvTzm7IAn1U5RAKMqtMsPa0FBE +LoxNtFEA/WJrGJX4C2EKlEo0GVz/OZQQID3JY9c61TPNO7QxE1IKzHFlmvOk6bhU+DG CB270zsEITloZiRbgaL5JUfINVq25TsWpJB0+kl9bzINacVzD7guyPuYCI/fjDX6dlK7 o1GCrJcU48vSsOPumNS0vORDaR2gKSGK973kUZ5j3ONQDPz5sjiVC6kIJ2MedhEt2b7K dLvg== 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=ot7QSzaLe/HM3r3BUS7EAlMprWtlPVH/1jMg0W1t8oM=; b=fXr248pDy8oitnIThoKf6lsAlPzvHLvLshCkM58G9T93Cy5MAquMAdlp3VKlh8Ge2x V8Chsd67dzCZY8yIScVgu1AOvTZyOYBLk1X/zIV6p8WR+Me2S1TODHJ2Kt7ex/XFbKZN j7ts309XampDvLM89PyKLkhSAzJ2fqFo/RkmFwpvh3grYS347rYV1dKfdkRraSIGaaGR OryJfgW+JlNXDD9UJLv8lydj1cEsw3UYUh5UKSjYEbv556xCtVp7U9GeQ0bKP2mYk3bA RBw5HuPj/sIGSkkjwkuQm/KErZj2c5gD0hVlrZN5FV3Y5VhO7MG9miKH2uzXNjQEFrQO /LbQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@google.com header.s=20161025 header.b=LMQFuypo; dkim=fail header.i=@chromium.org header.s=google header.b=PGaTQfhT; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a13si42037pgt.344.2018.02.10.11.24.49; Sat, 10 Feb 2018 11:25:03 -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=fail header.i=@google.com header.s=20161025 header.b=LMQFuypo; dkim=fail header.i=@chromium.org header.s=google header.b=PGaTQfhT; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752208AbeBJTYH (ORCPT + 99 others); Sat, 10 Feb 2018 14:24:07 -0500 Received: from mail-ua0-f196.google.com ([209.85.217.196]:37005 "EHLO mail-ua0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751945AbeBJTYA (ORCPT ); Sat, 10 Feb 2018 14:24:00 -0500 Received: by mail-ua0-f196.google.com with SMTP id q8so7236783uae.4 for ; Sat, 10 Feb 2018 11:23:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ot7QSzaLe/HM3r3BUS7EAlMprWtlPVH/1jMg0W1t8oM=; b=LMQFuyponKJtxzmgtLK36Rkm5fRiJRJ5dZGrOxJIptBt5QJYj0iefYz71OT9D1q546 x91ogIieD8QE4HpcQgq/SeEf7Lhfs1NqP/82Wmt5V545nUWbrcrnf4oNf09rkwFu+xmc A+1xaOZ26Ow2k1D+5dDQbeBJ2V1Xp1E7YtdEV31RID7EZQznzBW4uzLOxCnF+uZAtOUo IIW2xGudCpNYJ4ypquAdSncVEUNsbazex7+AHXKQhvnjDy8tTTmXfkxdrOuL+wjYtRzj NZdqV3tfanz8YabYJv1yTxVG5QkaonBBg3FHTRb6aGhKky+SiBYIQr+1B0n3jFMhr/cQ QK0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ot7QSzaLe/HM3r3BUS7EAlMprWtlPVH/1jMg0W1t8oM=; b=PGaTQfhT+Db1BKzpuFkrA8I/EajrjdA/zeM74FejNIIjEYC8rNkzoJte/5rqKNf+vL B2cOp+ad8Qt7VJe5Je/oeLFzWlfTk2GYsQP7aRamS3u71ptPNVi+L+2QOMwWIAlegLOe PQXmUYF2lkgG5e6scbcUBLFkAe5EjTxcP84Ec= 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=ot7QSzaLe/HM3r3BUS7EAlMprWtlPVH/1jMg0W1t8oM=; b=nLWPde6hirEzSAmyuJbl6L+UHuMsTa72HcxETokNx23CKXx4PPILNBjVlWx3quC21A WQmi/mbbp13MQWKxthhUV+yM+/Ghf6Yyk7y/v5EQ6/Xp3M6ValnyneDelITKoySVB6MU RZMkE6dHDyWyE6Ddk4uSt0CWOmSxZcCs4m+6e3fwd/5n+0LVXECp01wWRN/9m2p1NM77 gCDJMwUsOeGF9R9JblvmZ92Skgx2PW6JJEMUKfurCqMFxokahqFRUgTt0iLwRCC/plSr +SoEH0AJl/dqpOyBNqojv4n3duVnwAROlW4FGPfzNMyI5HTMQ5loawH1KDYwEXm5xsfh 29Yg== X-Gm-Message-State: APf1xPBbfozN835EVISfM9pg9wp3+CGmz4PkPFbijcL+fQlxiMScRAcm FrxkPFqO7xR/YuuuDmtnP3Ff6J3cy2LL4MbZzf6wWw== X-Received: by 10.176.112.181 with SMTP id q21mr6635029ual.105.1518290638874; Sat, 10 Feb 2018 11:23:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.67.196 with HTTP; Sat, 10 Feb 2018 11:23:58 -0800 (PST) In-Reply-To: <20180210085519.737ckf4bcl57h4g2@huvuddator> References: <1518106752-29228-1-git-send-email-yamada.masahiro@socionext.com> <1518106752-29228-5-git-send-email-yamada.masahiro@socionext.com> <20180209053038.pscoijvowmyudyzf@huvuddator> <20180209124607.akjhncb5sempjqcn@huvuddator> <20180210054843.z3g7wvcmlccvww3h@huvuddator> <20180210074924.3nhxsza5zdbaahxx@huvuddator> <20180210080556.mycqsjhxbaguwhay@huvuddator> <20180210085519.737ckf4bcl57h4g2@huvuddator> From: Kees Cook Date: Sat, 10 Feb 2018 11:23:58 -0800 X-Google-Sender-Auth: EBcKCEwW5MDsB4Cu03QGoepio3Q Message-ID: Subject: Re: [RFC PATCH 4/7] kconfig: support new special property shell= To: Ulf Magnusson Cc: Masahiro Yamada , Linux Kbuild mailing list , Linus Torvalds , Greg Kroah-Hartman , Andrew Morton , Nicolas Pitre , "Luis R . Rodriguez" , Randy Dunlap , Sam Ravnborg , Michal Marek , Martin Schwidefsky , Pavel Machek , linux-s390 , Jiri Kosina , Linux Kernel Mailing List 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 Sat, Feb 10, 2018 at 12:55 AM, Ulf Magnusson wrote: > Here's a complete updated example, with some stuff from Masahiro added. > > Turns out warnings inside choices get cut off easily in menuconfig, so I > went with just a single warning instead (which should be enough anyway). > > With this version, the only "outputs" that the Makefiles needs to look > at are CC_STACKPROTECTOR_{STRONG,REGULAR,NONE} (and > CC_OPT_STACKPROTECTOR). WANT_CC_OPT_STACKPROTECTOR_AUTO is handled > automatically. > > The caveat related to old .config files mentioned above still applies. > > How many compilers don't support -fno-stack-protector by the way? > > config CC_HAS_STACKPROTECTOR_STRONG > bool > option shell="$CC -Werror -fstack-protector-strong -c -x c /dev/null" > > config CC_HAS_STACKPROTECTOR_REGULAR > bool > option shell="$CC -Werror -fstack-protector -c -x c /dev/null" > > config CC_HAS_STACKPROTECTOR_NONE > bool > default y > option shell="$CC -Werror -fno-stack-protector -c -x c /dev/null" Instead of just $CC for these, we need the test script that runs with all the per-architecture flags configured and runs the actual _build_ test of the output. It is, unfortunately, not sufficient to test that the compiler supports the flag: it has to be tested to produce the correct output too, as there are continual regressions here (old compilers, misbuilt compilers, misconfigured compilers, etc). So, if this could do something like this: config CC_HAS_STACKPROTECTOR_STRONG bool option shell="scripts/gcc-${ARCH}_${BITS}-has-stack-protector.sh $CC $KBUILD_CPPFLAGS" then this could all work from Kconfig. > choice > prompt "Stack Protector buffer overflow detection" > default WANT_CC_STACKPROTECTOR_AUTO Otherwise, this WANT_ approach looks decent. > comment "Warning: Selected stack protector not available" > depends on !(CC_STACKPROTECTOR_STRONG || \ > CC_STACKPROTECTOR_REGULAR || \ > CC_STACKPROTECTOR_NONE) For WANT...AUTO, a warning is fine. for WANT...STRONG or WANT...REGULAR this must fail the build. > config CC_OPT_STACKPROTECTOR > string > default "-fstack-protector-strong" if CC_STACKPROTECTOR_STRONG > default "-fstack-protector" if CC_STACKPROTECTOR_REGULAR > default "-fno-stack-protector" if CC_HAS_STACKPROTECTOR_NONE > # If the compiler doesn't even support > # -fno-stack-protector > default "" > > Of course, at some point you're just moving complexity from one place to > another. Maybe this all-Kconfig approach isn't worth it if people find > it harder to understand. I don't know how bad the Makefiles are here at > the moment. FWIW, it feels more readable in Kconfig, if we can solve the circular issue of $KBUILD_CPPFLAGS... -Kees -- Kees Cook Pixel Security