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:   Thu, 12 Jan 2023 17:22:53 -0600
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Kees Cook <keescook@...omium.org>
Cc:     gregkh@...uxfoundation.org, kees@...nel.org, linux@...ck-us.net,
        vbabka@...e.cz, stable-commits@...r.kernel.org,
        linux-hardening@...r.kernel.org
Subject: Re: Patch "gcc: disable -Warray-bounds for gcc-11 too" has been added
 to the 6.1-stable tree

On Thu, Jan 12, 2023 at 3:50 PM Kees Cook <keescook@...omium.org> wrote:
>
> Linus, this seems like a really giant hammer for a single warning on a
> single architecture for an option that gives us real bug coverage. I'm
> not sure GCC 11 will be going away any time soon, either. Can we please
> limit this to either just the affected file, or at least just powerpc?

We did exactly that with the gcc-12 case. Grep for
GCC12_NO_ARRAY_BOUNDS, and see the remaining case on the s390 side,
because initially it was limited to s390.

That was initially thought to be just an issue with gcc not liking how
s390 has special "short" pointers that gcc thought were some kind of
NULL pointer thing and then always considered everything to be
out-of-bounds.

See commit 8b202ee21839 ("s390: disable -Warray-bounds").

... and then a few months later, it turns out that that s390-specific
issue wasn't the only thing wrong with -Warray-bounds, and we disabled
it everywhere.

See commit f0be87c42cbd ("gcc-12: disable '-Warray-bounds' universally
for now").

I'm not going to play this game again. There is nothing that says that
this is powerpc-specific, it's probably just a thing where it triggers
on powerpc for some completely random reason.

And compiler bugs are not some kind of "let's just pray and hope it
doesn't hit us anywhere else". If the compiler is buggy, it's buggy,
and we should make sure we don't hit that bug.

So if you can actually show *why* it happens, and show that yes, this
is limited to only powerpc, then we can revisit.

But right now it seems a matter of "just by luck, we don't hit it
anywhere else", and I'm not interested in playing any more
whack-a-mole with this broken compiler option.

                    Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ