From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: ARC-Seal: i=1; a=rsa-sha256; t=1518512141; cv=none; d=google.com; s=arc-20160816; b=E+FiN60uIZBgn8Q/Qj8h5PutUxBPxDB3l3viBgN5M9wbhdL2R3e0ePZffSL7z9klmL urMmNhThRQVQ+lQlR3c6gc20hKlTsgHszgLU1VHXMqWyceCdveQISJqxQeWDPihl0vKO PTNyfoRY5JcpnjN1fJa8hQc+ScrnX5b5MNsGoK7ZqUXfG4LWCk7KbgFSku9SS553+YFs r/H69+k3ExpOYLRTO9sJ2WzDu2l3xUcVFo4/7MKmwheBMfuynoJ2W6SMleyZkvHs8Rtu SsiHb1liislBVuV50Gtzsp9VHSVKpHisZHDljraBfh3ZeUMdkfkz3DemO5Nxv3yhgdl0 lgjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=C4J1weRpWcEftjdY3A6w/Eb22FdJy5wAgDh8DJ0lw7I=; b=jWzv+JCX/9nWoNL+CeE7xHKL/Sb4cDBfcA/Esh7WJAsPs6SpxtGdDZTkxzj18mk93x 6k4Vxsn25FSmW7MDtd2QhA6iHKDeSmw7pb4Vq/IDcRuZ4XEtY54/wjIZm7e/1HzQ92P2 T0V/rk2sVfHvGFvA+Z8sSq0qg8bqnkFL/Co5QqWxylPuKAqTQPJP68ZrHex51vtLyaL0 o9//yZbM43xhb4cmQF4WaJfKOs8Wn7xD9Dmo7Cxc+9HU5VR/cdRX6lwsUZqb8FZAKv/Z lMkSPt+YlHzMO/7lkh/MaU5OMKEeN480m7ALKF2KC4gUItyDOeM4/rSOLYiyBQBXlj8R y0SQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Yxv8112D; spf=pass (google.com: domain of ulfalizer@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=ulfalizer@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Yxv8112D; spf=pass (google.com: domain of ulfalizer@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=ulfalizer@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com X-Google-Smtp-Source: AH8x226okucpKtaLLLzvXEynmp9nIDS6TxYHx/iWdoJGhM6SJCClwFATrU1C90/MehaQb11Z+nuljw== Date: Tue, 13 Feb 2018 09:55:37 +0100 From: Ulf Magnusson To: Masahiro Yamada Cc: Kees Cook , Linus Torvalds , Linux Kbuild mailing list , 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 , Tejun Heo , Ingo Molnar , "Van De Ven, Arjan" Subject: Re: [RFC PATCH 4/7] kconfig: support new special property shell= Message-ID: <20180213085537.dj7w2hqdxucjpzl2@huvuddator> References: <20180210085519.737ckf4bcl57h4g2@huvuddator> <20180211103432.pf2ot6nd7nbhdhsy@huvuddator> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1591850368607646970?= X-GMAIL-MSGID: =?utf-8?q?1592275386624743034?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Tue, Feb 13, 2018 at 01:10:34AM +0900, Masahiro Yamada wrote: > 2018-02-13 0:46 GMT+09:00 Kees Cook : > > On Mon, Feb 12, 2018 at 2:44 AM, Masahiro Yamada > > wrote: > >> Linus said: > >> > >>> But yes, I also reacted to your earlier " It can't silently rewrite it > >>> to _REGULAR because the compiler support for _STRONG regressed." > >>> Because it damn well can. If the compiler doesn't support > >>> -fstack-protector-strong, we can just fall back on -fstack-protector. > >>> Silently. No extra crazy complex logic for that either. > >> > >> > >> If I understood his comment correctly, > >> we do not need either WANT_* or _AUTO. > >> > >> > >> Kees' comment: > >> > >>> In the stack-protector case, this becomes quite important, since the > >>> goal is to record the user's selection regardless of compiler > >>> capability. For example, if someone selects _REGULAR, it shouldn't > >>> "upgrade" to _STRONG. (Similarly for _NONE.) > >> > >> No. Kconfig will not do this silently. > >> > >> "make oldconfig" (or "make silentoldconfig" as well) > >> always ask users about new symbols. > > > > The case I want to make sure can never happen is to have a config > > setting that ends up not actually being true. For example, if > > CONFIG_CC_STACKPROTECTOR appears in /proc/config.gz but the kernel > > wasn't actually built with a stack protector, that's bad. We end up in > > a place where the user can't trust the config to represent the actual > > results of the build. > > > > So, as long as the Kconfig options are strongly tied to the compiler > > capabilities, we're good on that front. > > > >> So, I can suggest to remove _REGULAR and _NONE. > >> > >> We have just two bool options, like follows. > >> > >> ------------------->8----------------- > >> config CC_STACKPROTECTOR > >> bool "Use stack protector" > >> depends on CC_HAS_STACKPROTECTOR > >> > >> config CC_STACKPROTECTOR_STRONG > >> bool "Use strong strong stack protector" > >> depends on CC_STACKPROTECTOR > >> depends on CC_HAS_STACKPROTECTOR_STRONG > >> -------------------->8------------------ > >> > >> This will work well for all{yes,mod,no}config. > > > > This two-option arrangement is fine (though it assumes there won't be > > another stack protector option in the future). > > > > The issue I have is this removes _AUTO, which I think can be solved in > > the two-option arrangement too. The purpose of _AUTO is to effectively > > enable stack-protector by default. As this option has been available > > for over 10 years, and all distros enable it, it's an obvious > > candidate to be enabled-by-default, especially since it kills a class > > of exploits (as mentioned in my commit log: BlueBorne was trivially > > defeated with stack-protector). So it should be possible to make these > > two options "default y", yes? > > > Yes. > > Both should be "default y" to keep the equivalent behavior > since the current default is _AUTO. > Since the discussions in this thread are going in a million different directions and making my head hurt, ping me if I'm needed re. the WANT_* stuff or anything else. Masahiro's two-symbol version is much simpler and neater if the caveats re. "fallback" are minor enough to not matter. :) Cheers, Ulf