linux-hardening - Re: [PATCH] gcc-plugins: Disable GCC_PLUGIN_CYC

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]

Date:   Tue, 23 Feb 2021 09:41:40 -0800
From:   Guenter Roeck <linux@...ck-us.net>
To:     Heiko Carstens <hca@...ux.ibm.com>
Cc:     Masahiro Yamada <masahiroy@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        linux-hardening@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...nel.org>
Subject: Re: [PATCH] gcc-plugins: Disable GCC_PLUGIN_CYC_COMPLEXITY for s390

On Tue, Feb 23, 2021 at 12:54:10PM +0100, Heiko Carstens wrote:
> On Mon, Feb 22, 2021 at 08:03:31AM -0800, Guenter Roeck wrote:
> > > Maybe, we can add something like CONFIG_SUPPRESS_NOISY_TESTS,
> > > which is set to y by all{yes,mod}config.
> > > 
> > > This is self-documenting, so we do not need the '# too noisy' comment.
> > > 
> > > 
> > > 
> > > config SUPPRESS_NOISY_TESTS
> > >        bool "suppress noisy test"
> > > 
> > > 
> > > config GCC_PLUGIN_CYC_COMPLEXITY
> > >         bool "Compute the cyclomatic complexity of a function" if EXPERT
> > >         depends on !SUPPRESS_NOISY_TESTS
> > > 
> > 
> > Good idea. Downside would be that it won't solve the real problem
> > for s390 (which is lack of allmodconfig/allyesconfig compile test
> > coverage because COMPILE_TEST isn't set anymore), but that is a
> > different problem anyway, and my original patch doesn't solve
> > that either.
> 
> I tried to explain why we don't want to set COMPILE_TEST for s390
> anymore. It overrides architecture dependencies in Kconfig, and lots
> of drivers do not set dependencies for HAS_IOMEM, HAS_DMA, and friends
> correctly.
> This generates constantly fallout which is irrelevant for s390 and
> also for other architectures. It generates just work with close to
> zero benefit. For drivers which matter for s390 we still see those
> errors.
> 
> > On the other side, if that flag would be set explicitly by
> > all{yes,mod}config, it would really beg for being misused. We
> > might then as well add a new flag that is explicitly associated
> > with all{yes,mod}config, but not with randconfig.
> 
> I think that makes most sense, probably also have a flag that is set
> for randconfig.

Not sure what value such an option would have, and how it would be used.
I would argue that randconfig should not set COMPILE_TEST to start with,
since its purpose should be to test random valid configurations and not
to compile test arbitrary (and in that case random) code. But that is
a different question, and just my personal opinion.

Overall, the question is what kind of additional option you would find
useful for s390. You make it clear that you don't want COMPILE_TEST.
At the same time, you still want all{mod,yes}config, but presumably
excluding options currently restricted by !COMPILE_TEST (such as
DEBUG_INFO, BPF_PRELOAD, UBSAN_TRAP, GCC_PLUGIN_CYC_COMPLEXITY,
and a few others). SUPPRESS_NOISY_TESTS would not cover that, but
neither would RANDCONFIG (or whatever it would be called).

Guenter