From: Kees Cook <kees@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Jeff Johnson <quic_jjohnson@quicinc.com>,
linux-hardening@vger.kernel.org,
open list <linux-kernel@vger.kernel.org>
Subject: Re: mips gcc plugin issues
Date: Wed, 19 Jun 2024 14:17:44 -0700 [thread overview]
Message-ID: <202406191414.67C589A@keescook> (raw)
In-Reply-To: <f1f08297-e8c7-4673-88b5-e9b6bff69371@app.fastmail.com>
On Wed, Jun 19, 2024 at 11:12:25PM +0200, Arnd Bergmann wrote:
> On Wed, Jun 19, 2024, at 22:50, Kees Cook wrote:
> > On Tue, Jun 18, 2024 at 04:41:01PM -0700, Jeff Johnson wrote:
> >> I see the following in my .config:
> >> CONFIG_HAVE_GCC_PLUGINS=y
> >> CONFIG_GCC_PLUGINS=y
> >> CONFIG_GCC_PLUGIN_LATENT_ENTROPY=y
> >> CONFIG_GCC_PLUGIN_RANDSTRUCT=y
> >>
> >> So I'll turn those off, but just want to flag that this issue exists.
> >> Seems either the plugins should work or the allmodconfig should turn them off.
> >
> > Well, the plugins work with all the other compiler versions all the
> > various CI systems use. :) For example, I don't see this with distro
> > cross compilers:
> >
> > $ mipsel-linux-gnu-gcc --version
> > mipsel-linux-gnu-gcc (Ubuntu 12.3.0-1ubuntu1) 12.3.0
> >
> > I suspect this is a problem with the kernel.org crosstool builds? I'm
> > CCing Arnd, who might know more about this.
>
> Yes, this is a known problem, and I don't think there is a good
> solution for it, compiler plugins on cross-compilers are inherently
> fragile.
>
> The problem here is that a gcc plugin links against the
> compiler, not against code produced by it. I'm linking the
> crosstool compilers statically against libraries as much as
> possible in order to make them more portable between distros,
> but the downside of that is that plugins will only work in
> the environment that I was using to build these toolchains.
>
> My build environment is an older Debian (in order to be
> portable to old glibc versions), but with the system compiler
> updated to gcc-13 (since x86 libgcc cannot be cross-compiled
> with an older compiler).
Can the crosstools remove the plugin support? That seems like the best
solution. Kconfig test for plugin availability with:
depends on $(success,test -e $(shell,$(CC) -print-file-name=plugin)/include/plugin-version.h)
> The long-term solution of course is to replace all the
> gcc plugins with some other way of getting the same
> features, but that will still take some time.
Agreed. There's not much motion on the GCC side of this, though.
--
Kees Cook
next prev parent reply other threads:[~2024-06-19 21:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-18 23:41 mips gcc plugin issues Jeff Johnson
2024-06-19 20:50 ` Kees Cook
2024-06-19 21:12 ` Arnd Bergmann
2024-06-19 21:17 ` Kees Cook [this message]
2024-06-20 5:10 ` Arnd Bergmann
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=202406191414.67C589A@keescook \
--to=kees@kernel.org \
--cc=arnd@arndb.de \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_jjohnson@quicinc.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.