linux-kernel - Re: [RFC PATCH 0/7] Kconfig: add new special property shell= to test compiler options in Kconfig

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFxpxAGkCTvugOAXp+izb8O1C5YD+ExMQ27uYVU3-97P1A@mail.gmail.com>
Date:   Thu, 8 Feb 2018 09:19:34 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:     Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Kees Cook <keescook@...omium.org>,
        Nicolas Pitre <nicolas.pitre@...aro.org>,
        "Luis R . Rodriguez" <mcgrof@...e.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Ulf Magnusson <ulfalizer@...il.com>,
        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>
Subject: Re: [RFC PATCH 0/7] Kconfig: add new special property shell= to test
 compiler options in Kconfig

On Thu, Feb 8, 2018 at 8:19 AM, Masahiro Yamada
<yamada.masahiro@...ionext.com> wrote:
> This was prompted by the email from Linus today's morning.

Thanks.

> I implmented this in a rush today, so there are still many TODOs,
> but I put it here to start discussion.
>
> I think it is working, but as you notice, it is tedious to repeat something
> like follows:
>
> config CC_HAS_STACKPROTECTOR
>         bool
>         option shell="$CC -Werror -fstack-protector -c -x c /dev/null"

Yeah.

I do think we want to have the "shell" thing as a generic escape for
other things too, but *realistically*, the primary target for this is
compiler flags, and I think we should target that specifically with a
shorthand.

Doing some statistics, and looking for

    flag = $(call xyz ...)

patterns in our makefiles (ignoring single uses), it really is
cc-option that dominates:

      2  name-fix
      2  try-run
      3  __cc-option
      3  grep-libs
      3  strip-libs
      4  flags
      4  get-executable
      4  ld-option
      4  logo-cfiles
      5  as-option
      5  cc-cross-prefix
      6  cc-ldoption
      6  cc-supports
      7  cc-option-yn
      7  tune
      9  cc-ifversion
     30  as-instr
     48  cc-disable-warning
    239  cc-option

so I think that's the one that we want to special-case.

If we then have a _usable_ - but perhaps not wonderful "shell" escape
to do any random thing (including scripts etc), that will take care of
the rest, but cc-option is so common that I think it's worth making a
special Kconfig syntax for them. For all I know, the others aren't
even worth Kconfig options at all.

> I was thinking of something like follows:
>
> config CC_STACKPROTECTOR
>           bool
>           option shell="$(CC_OPTION -fstack-protector)"

I think we should go even further, and just make it be

config CC_STACKPROTECTOR
          bool
          option cc_option="-fstack-protector"

and actually have the Kconfig language itself have this special-cased.

And obviously that "option cc_option" would be *implemented* as just
"option shell", with just some stupid string substitution. So it
really would be purely a shorthand for readability.

What do you think?

And btw, the patches look nice. What I like in particular is that they
don't even seem to add a lot of lines: the new shell option code is
almost balanced out by the Kconfig script simplifications. And maybe
it's just that I read C a lot better than I read GNU Makefile magic,
but I think it's more understandable too.

                  Linus