[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFkk2KQBCUT84rH22-+e6=hstQcdcpKQ7SM8=0SshrQ++vbMKg@mail.gmail.com>
Date: Sun, 11 Feb 2018 22:22:04 +0100
From: Ulf Magnusson <ulfalizer@...il.com>
To: Kees Cook <keescook@...omium.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Nicolas Pitre <nicolas.pitre@...aro.org>,
"Luis R . Rodriguez" <mcgrof@...e.com>,
Randy Dunlap <rdunlap@...radead.org>,
Sam Ravnborg <sam@...nborg.org>,
Michal Marek <michal.lkml@...kovi.net>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
Pavel Machek <pavel@....cz>,
linux-s390 <linux-s390@...r.kernel.org>,
Jiri Kosina <jkosina@...e.cz>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Tejun Heo <tj@...nel.org>, Ingo Molnar <mingo@...nel.org>,
"Van De Ven, Arjan" <arjan.van.de.ven@...el.com>,
Arnd Bergmann <arnd@...db.de>
Subject: Re: [RFC PATCH 4/7] kconfig: support new special property shell=
On Sun, Feb 11, 2018 at 6:56 PM, Kees Cook <keescook@...omium.org> wrote:
>> 3. Whether to implement CC_STACKPROTECTOR_AUTO in Kconfig or the Makefiles
>>
>> I'd just go with whatever is simplest here. I don't find the Kconfig version
>> too bad, but I'm already very familiar with Kconfig, so it's harder for me to
>> tell how it looks to other people.
>>
>> I'd add some comments to explain the idea in the final version.
>>
>> @Kees:
>> I was assuming that the Makefiles would error out with a message if none of the
>> CC_STACKPROTECTOR_* variables are set, in addition to the Kconfig warning.
>
> That doesn't happy either before nor after _AUTO. The default value
> before was _NONE, and the default value after is _AUTO, which will use
> whatever is available.
I was thinking in the case where you explicitly select one of
CC_STACKPROTECTOR_{STRONG,REGULAR} and it isn't available. With the
new WANT_* version, that will cause none of
CC_STACKPROTECTOR_{STRONG,REGULAR,NONE} to be set, and in that case
you'd error out to match the old behavior (if I understand it
correctly).
CHOSEN_CC_STACKPROTECTOR_AVAILABLE would just be a helper symbol to
detect that case. It's not like it's a huge deal to detect it on the
Makefile end either, but turns it pretty nice and readable, IMO, with
more of the logic in a single location.
>> # User request
>> WANT_CC_STACKPROTECTOR_AUTO
>> WANT_CC_STACKPROTECTOR_STRONG
>> WANT_CC_STACKPROTECTOR_REGULAR
>> WANT_CC_STACKPROTECTOR_NONE
>>
>> # The actual "output" to the Makefiles
>> CC_STACKPROTECTOR_STRONG
>> CC_STACKPROTECTOR_REGULAR
>> CC_STACKPROTECTOR_NONE
>
> This should be fine too (though by this point, I think Kconfig would
> already know the specific option, so it could just pass it with a
> single output (CC_OPT_STACKPROTECTOR below?)
Ah, yeah, that'd be simpler if all that's needed is the compiler flag.
Cheers,
Ulf
Powered by blists - more mailing lists