Re: [PATCH] s390: disable -Warray-bounds

[Kees Cook <keescook@chromium.org>]

On Wed, Jun 08, 2022 at 01:07:05PM -0700, Linus Torvalds wrote:
> Coming back to this, because my rc2 week tends to be quiet as people
> take a breather, and as such a good time for me to do system upgrades.
> 
> And gcc-12 dropped in Fedora 36, and shows problems on x86 too.
> 
> So I suspect we'll have to disable -Warray-bounds globally on gcc-12,
> not just on s390.
> 
> Unless Kees has patches ready to go already.

I and others have been working through a bunch of them, though yes,
they're not all fixed yet. I've been trying to track it here[1], but
many of those fixes are only in -next.

> Some of the warnings look potentially simple, ie
> 
>    struct mbus_dram_target_info;
> 
> in <linux/mbus.h> has the comment
> 
>          *   [..]  Peripherals are
>          * required to support at least 4 decode windows.
> 
> and then as a result has
> 
>         int             num_cs;
>         struct mbus_dram_window {
>            [..]
>         } cs[4];
> 
> and that "cs[4]" looks just bogus - it can be a much larger array, the
> '4' is just a minimum. The real limit is that 'num_cs' one.
> 
> But there's a *lot* of warnings, and many of them are due to this, and
> while some are obvious, others aren't.

When I did a count in -next 2 weeks ago, there were 182 warnings (x86
allmodconfig) from GCC 12 where 153 were from -Warray-bounds. Today
we're now down to 80 total (61 from -Warray-bounds), so we've solved
over half of them.

> There are other things too in gcc-12 that seem half-baked. I was
> interested to see the new '-Wdangling-pointer' thing, but then when I
> looked at it, the two cases I looked at were just bogus, so ..

Yes, GCC 12 is very odd in places. Besides the literal-as-pointer issue
that still causes problems for s390[2], there seem to be at least a
few other bugs associated with the internal diagnostics infrastructure
that informs -Warray-bounds, -Wstringop-overflow, etc. I narrowed down
one recently with UBSAN_BOUNDS[3] (which therefore impacts all*config
builds), but there is no GCC fix yet. :(

So, it's unclear to me if we want to try to get back to 0 warnings
(where we were with v5.18 and GCC 11) in the next couple weeks, or if we
need to just disable it for GCC 12 until everything is fixed again.

-Kees

[1] https://github.com/KSPP/linux/issues/190
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679

-- 
Kees Cook