All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <kees@kernel.org>
To: Richard Biener <richard.guenther@gmail.com>
Cc: Jan Hubicka <hubicka@ucw.cz>, Richard Biener <rguenther@suse.de>,
	Martin Jambor <mjambor@suse.cz>,
	gcc-patches@gcc.gnu.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH] ipa-icf: Compare access path type sizes without TBAA [PR105438]
Date: Wed, 14 Oct 2026 22:24:57 -0700	[thread overview]
Message-ID: <20261015052441.7d2b3c-kees@kernel.org> (raw)
In-Reply-To: <CAFiYyc2gYAjiKDi+TeC9_qEX+LHa7fSxj42JjRtM6Dbi6Yfidw@mail.gmail.com>

On Sun, Oct 11, 2026 at 04:50:41PM +0200, Richard Biener wrote:
> >     In function 'small_to_big', inlined from 'f' at t.c:22:3:
> >     warning: array subscript 'struct big[0]' is partly outside array bounds of 'struct small[1]' [-Warray-bounds=]
>
> I think these diagnostics are dubious with -fno-strict-aliasing which
> essentially says you can access every object via any other objects type.

The source has no such access, though: each function reads and writes
members through its own types, and every byte touched is inside the
object. The "struct big" access to a "struct small" exists only in the
body ICF picked, so the warning is about code GCC wrote rather than
code the programmer wrote.

> So instead of this I'd rather work towards inlining the original
> body rather than the ICF prevailing one.

That does seem like it could be better, but it's not clear to me how
large a project that would be to accomplish.

This patch seems to DTRT, though. It doesn't appear to regress merging
in a meaningful way for the Linux at least.

> And force-disable these kind of diagnostics with -fno-strict-aliasing?

I'd really rather not. Linux builds everything with -fno-strict-aliasing,
so that would remove these checks from the kernel entirely. GCC's
-Warray-bounds is still off by default for the kernel because of false
positives like this one (which is why I'm trying to solve it), and I've
been working toward enabling it, since it finds real bugs. (I have a
stack of a dozen real issues that this found while doing a recent pass.)

For example (since I don't yet have links to the above stack), here
are some random examples from a few years ago: a response struct passed
where a bigger error struct was expected, whose "error" field was past
the end of the object[1]:

  drivers/thunderbolt/xdomain.c:226:22: error: array subscript 'const struct tb_xdp_error_response[0]' is partly outside array bounds of 'struct tb_xdp_properties_changed_response[1]'

and a u64 remainder stored into an int on the stack[2]:

  include/linux/math64.h:56:20: error: array subscript 'u64 {aka long long unsigned int}[0]' is partly outside array bounds of 'int[1]'

But if you did disable diagnostics, which did you have in mind? If it's
only warnings about an access whose type is bigger than the object while
the bytes it touches are in bounds, that's narrower, but the first
example above would still need to be caught, so I'd much rather just
get ICF behaving nicely. :)

-Kees

[1] https://git.kernel.org/linus/19813551701d0
[2] https://git.kernel.org/linus/9f3d543a9f737

-- 
Kees Cook

  reply	other threads:[~2026-10-15  5:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-10  5:05 [PATCH] ipa-icf: Compare access path type sizes without TBAA [PR105438] Kees Cook
2026-10-11 14:50 ` Richard Biener
2026-10-15  5:24   ` Kees Cook [this message]
2026-10-15  7:33     ` Richard Biener
2026-10-15  8:58       ` Richard Biener
2026-10-15 12:04         ` Richard Biener
2026-10-15 21:53           ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261015052441.7d2b3c-kees@kernel.org \
    --to=kees@kernel.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    --cc=linux-hardening@vger.kernel.org \
    --cc=mjambor@suse.cz \
    --cc=rguenther@suse.de \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.