linux-kernel - Re: [PATCH v2 20/21] gcc-plugins: enable GCC_PLUGINS for COMPILE

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: <CAK7LNATJidxieoNoo=CTk_-BpKJv8dwq+q1MAmsRDivd6ZrotQ@mail.gmail.com>
Date:   Tue, 10 Apr 2018 15:15:43 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Kees Cook <keescook@...omium.org>
Cc:     linux-kbuild <linux-kbuild@...r.kernel.org>,
        Sam Ravnborg <sam@...nborg.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Arnd Bergmann <arnd@...db.de>,
        Ulf Magnusson <ulfalizer@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        "Luis R . Rodriguez" <mcgrof@...nel.org>,
        Nicolas Pitre <nico@...aro.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 20/21] gcc-plugins: enable GCC_PLUGINS for COMPILE_TEST

2018-03-28 20:47 GMT+09:00 Kees Cook <keescook@...omium.org>:
> On Mon, Mar 26, 2018 at 10:29 PM, Masahiro Yamada
> <yamada.masahiro@...ionext.com> wrote:
>> The plugin availability is checked in Kconfig, so all{yes,mod}config
>> will not be bothered.  Remove 'depends on !COMPILE_TEST'.
>>
>> Signed-off-by: Masahiro Yamada <yamada.masahiro@...ionext.com>
>> ---
>>
>> Changes in v2:
>>   - Remove more 'depends on'
>>
>>  arch/Kconfig | 4 ----
>>  1 file changed, 4 deletions(-)
>>
>> diff --git a/arch/Kconfig b/arch/Kconfig
>> index 88cc925..b07094c 100644
>> --- a/arch/Kconfig
>> +++ b/arch/Kconfig
>> @@ -414,7 +414,6 @@ menuconfig GCC_PLUGINS
>>         bool "GCC plugins"
>>         depends on HAVE_GCC_PLUGINS
>>         depends on $(success $srctree/scripts/gcc-plugin.sh $HOSTCXX $CC)
>> -       depends on !COMPILE_TEST
>>         help
>>           GCC plugins are loadable modules that provide extra features to the
>>           compiler. They are useful for runtime instrumentation and static analysis.
>
> This one is nice, yes! We get coverage for anyone with plugin support.
>
>> @@ -424,7 +423,6 @@ menuconfig GCC_PLUGINS
>>  config GCC_PLUGIN_CYC_COMPLEXITY
>>         bool "Compute the cyclomatic complexity of a function" if EXPERT
>>         depends on GCC_PLUGINS
>> -       depends on !COMPILE_TEST
>>         help
>>           The complexity M of a function's control flow graph is defined as:
>>            M = E - N + 2P
>> @@ -487,7 +485,6 @@ config GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
>>  config GCC_PLUGIN_STRUCTLEAK_VERBOSE
>>         bool "Report forcefully initialized variables"
>>         depends on GCC_PLUGIN_STRUCTLEAK
>> -       depends on !COMPILE_TEST
>>         help
>>           This option will cause a warning to be printed each time the
>>           structleak plugin finds a variable it thinks needs to be
>> @@ -527,7 +524,6 @@ config GCC_PLUGIN_RANDSTRUCT
>>  config GCC_PLUGIN_RANDSTRUCT_PERFORMANCE
>>         bool "Use cacheline-aware structure randomization"
>>         depends on GCC_PLUGIN_RANDSTRUCT
>> -       depends on !COMPILE_TEST
>>         help
>>           If you say Y here, the RANDSTRUCT randomization will make a
>>           best effort at restricting randomization to cacheline-sized
>
> All three of these, though, please leave as they were. They're either
> needlessly noisy for COMPILE_TEST (GCC_PLUGIN_CYC_COMPLEXITY and
> *_VERBOSE),


CONFIG_GCC_PLUGIN_CYC_COMPLEXITY is crazily annoying.
I wonder if the right thing might be to dump the log to
a separate report file instead of messing up the console,
but this is a different issue.
So I will keep this as-is.




CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE prinkles
 'userspace variable will be forcibly initialized'

If this is a matter of warning level,
we generally control this by W= option
as you see in scripts/Makefile.extrawarn

But, maybe I am wrong.  I will keep this as-is
until I figure out what is the right thing to do
for warning verbosity.




> or reduce the COMPILE_TEST coverage
> (GCC_PLUGIN_RANDSTRUCT_PERFORMANCE).
>

Can you explain a bit more about GCC_PLUGIN_RANDSTRUCT_PERFORMANCE?

IIUC, this option reduces the randomization.

Is it related to COMPILE_TEST coverage?






> (And perhaps a comment is needed to explain these to avoid confusion
> in the future?)
>
> -Kees
>
> --
> Kees Cook
> Pixel Security
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Masahiro Yamada