All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: Bill Wendling <morbo@google.com>
Cc: Kees Cook <kees@kernel.org>, Vincent Mailhol <mailhol@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Justin Stitt <justinstitt@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH 2/2] randstruct: report bad casts as warnings rather than notes
Date: Fri, 4 Sep 2026 13:24:15 -0700	[thread overview]
Message-ID: <20260904202415.GA2787252@ax162> (raw)
In-Reply-To: <CAGG=3QUHtqFVCEcnxXO9fan_RBT_jjWtBbA8ECpQeiC1dKMnvg@mail.gmail.com>

On Fri, Sep 04, 2026 at 11:14:19AM -0700, Bill Wendling wrote:
> Hi Kees,
> 
> On Thu, Sep 3, 2026 at 4:24 PM Kees Cook <kees@kernel.org> wrote:
> >
> > find_bad_casts() reports a cast between two randomized structure pointer
> > types with inform(), which renders as a "note:". It has done so since
> > the plugin was originally added, while using error() freely for attribute
> > misuse, UAPI structs, and version mismatches.
> >
> > Clang's implementation of the same check has always been stricter:
> > it rejects such a cast as a full error. There is no reason for the GCC
> > side to be effectively silent about the same problem.
> >
> > Build tested ARCH=x86_64 with CONFIG_RANDSTRUCT_FULL=y and GCC 14.2.0:
> > allmodconfig clean, and defconfig clean under three different random
> > seeds. A deliberate bad cast is still reported, now as a warning, at the
> > correct line and column.
> >
> > Signed-off-by: Kees Cook <kees@kernel.org>
> > ---
> >  scripts/gcc-plugins/randomize_layout_plugin.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/scripts/gcc-plugins/randomize_layout_plugin.c b/scripts/gcc-plugins/randomize_layout_plugin.c
> > index e2bd9ba08089..1e66f45fe29b 100644
> > --- a/scripts/gcc-plugins/randomize_layout_plugin.c
> > +++ b/scripts/gcc-plugins/randomize_layout_plugin.c
> > @@ -22,7 +22,7 @@
> >  #define ORIG_TYPE_NAME(node) \
> >         (TYPE_NAME(TYPE_MAIN_VARIANT(node)) != NULL_TREE ? ((const unsigned char *)IDENTIFIER_POINTER(TYPE_NAME(TYPE_MAIN_VARIANT(node)))) : (const unsigned char *)"anonymous")
> >
> > -#define INFORM(loc, msg, ...)  inform(loc, "randstruct: " msg, ##__VA_ARGS__)
> > +#define INFORM(loc, msg, ...)  warning_at(loc, 0, "randstruct: " msg, ##__VA_ARGS__)
> 
> Why not make this an error instead of a warning?

Yeah, it seems odd to mention that Clang's implementation has always
treated this as an error then not match its behavior. If this cannot be
made an error, I think the commit message should call out why.

-- 
Cheers,
Nathan

  reply	other threads:[~2026-09-04 20:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-03 23:24 [PATCH 0/2] randstruct: fix container_of() false positives after __mptr removal Kees Cook
2026-09-03 23:24 ` [PATCH 1/2] " Kees Cook
2026-09-03 23:24 ` [PATCH 2/2] randstruct: report bad casts as warnings rather than notes Kees Cook
2026-09-04 18:14   ` Bill Wendling
2026-09-04 20:24     ` Nathan Chancellor [this message]
2026-09-05  0:48     ` 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=20260904202415.GA2787252@ax162 \
    --to=nathan@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=justinstitt@google.com \
    --cc=kees@kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mailhol@kernel.org \
    --cc=morbo@google.com \
    --cc=ndesaulniers@google.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.