[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202406191414.67C589A@keescook>
Date: Wed, 19 Jun 2024 14:17:44 -0700
From: Kees Cook <kees@...nel.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Jeff Johnson <quic_jjohnson@...cinc.com>,
linux-hardening@...r.kernel.org,
open list <linux-kernel@...r.kernel.org>
Subject: Re: mips gcc plugin issues
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
Powered by blists - more mailing lists