linux-kernel - Re: [GIT PULL] Enable -Wimplicit-fallthrough for Clang for 5.14-rc7

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] [day] [month] [year] [list]

Date:   Thu, 19 Aug 2021 13:37:20 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Nathan Chancellor <nathan@...nel.org>
Cc:     "Gustavo A. R. Silva" <gustavoars@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        linux-hardening@...r.kernel.org
Subject: Re: [GIT PULL] Enable -Wimplicit-fallthrough for Clang for 5.14-rc7

On Thu, Aug 19, 2021 at 1:17 PM Nathan Chancellor <nathan@...nel.org> wrote:
>
> For what it's worth, clang's version of -Wimplicit-fallthrough would
> have caught the bug in commit 652b44453ea9 [..]

The thing is, any warning can catch a bug. The "signed pointer"
warnings could catch things too if people really care about "unsigned
char *" vs just plain "char *".

But warnings that have too many false positives are more likely to
hide bugs than expose them. So it's very much a balancing act.

I personally think that false positives are deadly: I'd much rather
have a c completely clean build where are the warnings are big red
flags, than a build that has warnings that _may_ be signs of bugs, but
where you have known false positives that have no sane workaround.

Because with even a _single_ false positive, people will immediately
just stop caring about any other warnings at all. We've seen that over
and over again.

This is why a compiler warning - to be useful - has to be completely
unambiguously about bad code, or at least have a alternate "good code
pattern" that is no worse than the code that the warning about.

> However, if you are truly opposed to a version check, can we at least
> just check for the presence of -Wunreachable-code-fallthrough as I
> suggested before?

I'm ok with that, since at that point there are no false warnings.

But even then, it's much too late for 5.14 by now, considering that
this has had issues, and that we already enable the warnings on the
common gcc builds.

                Linus