[PATCH] gcc-plugins: Disable GCC plugins for compile test builds

[PATCH] gcc-plugins: Disable GCC plugins for compile test builds

[Mark Brown]

In current mainline x86_64 allmodconfig builds done with tuxmake GCC 13
and GCC 14 toolchains (which are Debian ones packaged up into containers)
generate ICEs in landlock:

Event                            | Plugins
PLUGIN_FINISH_TYPE               | randomize_layout_plugin
PLUGIN_FINISH_DECL               | randomize_layout_plugin
PLUGIN_ATTRIBUTES                | latent_entropy_plugin randomize_layout_plugin
PLUGIN_START_UNIT                | latent_entropy_plugin stackleak_plugin
PLUGIN_ALL_IPA_PASSES_START      | randomize_layout_plugin
/build/stage/linux/security/landlock/fs.c: In function ‘hook_file_ioctl_common’:
/build/stage/linux/security/landlock/fs.c:1745:61: internal compiler error: in c
ount_type_elements, at expr.cc:7075
 1745 |                         .u.op = &(struct lsm_ioctlop_audit) {
      |                                                             ^

Arnd bisected this to c56f649646ec ("landlock: Log mount-related
denials") but that commit is fairly obviously not really at fault here,
most likely this is an issue in the plugin.  Given how disruptive having
key configs like this failing let's disable the plugins for compile test
builds until a fix is found.

Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 scripts/gcc-plugins/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/gcc-plugins/Kconfig b/scripts/gcc-plugins/Kconfig
index e383cda05367..29b03c136165 100644
--- a/scripts/gcc-plugins/Kconfig
+++ b/scripts/gcc-plugins/Kconfig
@@ -7,6 +7,7 @@ config HAVE_GCC_PLUGINS
 
 menuconfig GCC_PLUGINS
 	bool "GCC plugins"
+	depends on !COMPILE_TEST
 	depends on HAVE_GCC_PLUGINS
 	depends on CC_IS_GCC
 	depends on $(success,test -e $(shell,$(CC) -print-file-name=plugin)/include/plugin-version.h)

---
base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8
change-id: 20250407-kbuild-disable-gcc-plugins-8701aa609cb3

Best regards,
-- 
Mark Brown <broonie@kernel.org>

Re: [PATCH] gcc-plugins: Disable GCC plugins for compile test builds

[Linus Torvalds]

On Mon, 7 Apr 2025 at 14:10, Mark Brown <broonie@kernel.org> wrote:
>
> Arnd bisected this to c56f649646ec ("landlock: Log mount-related
> denials") but that commit is fairly obviously not really at fault here,
> most likely this is an issue in the plugin.  Given how disruptive having
> key configs like this failing let's disable the plugins for compile test
> builds until a fix is found.

I'm not against this, but I do want to bring up the "are the plugins
worth having at all" discussion again.

They've been a pain before. Afaik, the actual useful cases are now
done by actual real compiler support (and by clang, at that).

Who actually *uses* the gcc plugins? They just worry me in general,
and this is not the first time they have caused ICE problems.

            Linus

Re: [PATCH] gcc-plugins: Disable GCC plugins for compile test builds

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]

On Mon, Apr 07, 2025 at 02:33:40PM -0700, Linus Torvalds wrote:
> On Mon, 7 Apr 2025 at 14:10, Mark Brown <broonie@kernel.org> wrote:

> > Arnd bisected this to c56f649646ec ("landlock: Log mount-related
> > denials") but that commit is fairly obviously not really at fault here,
> > most likely this is an issue in the plugin.  Given how disruptive having
> > key configs like this failing let's disable the plugins for compile test
> > builds until a fix is found.

> I'm not against this, but I do want to bring up the "are the plugins
> worth having at all" discussion again.

> They've been a pain before. Afaik, the actual useful cases are now
> done by actual real compiler support (and by clang, at that).

> Who actually *uses* the gcc plugins? They just worry me in general,
> and this is not the first time they have caused ICE problems.

There was a bit of discussion of that on IRC which didn't summon up huge
enthusiasm for them.  Arnd noted that:

    https://github.com/nyrahul/linux-kernel-configs

indicates that Talos 1.9.1 uses latent_entropy (but we didn't check how
accurate that survey is).  He also noted that GCC_PLUGIN_SANCOV is
obsolete as of GCC 6 (!) and both CC_HAVE_STACKPROTECTOR_TLS and
GCC_PLUGIN_STRUCTLEAK_BYREF_ALL as of GCC 12, Ard indicated he wasn't
worried about loosing CC_HAVE_STACKPROTECTOR_TLS.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] gcc-plugins: Disable GCC plugins for compile test builds

[Arnd Bergmann]

On Tue, Apr 8, 2025, at 00:02, Mark Brown wrote:
> On Mon, Apr 07, 2025 at 02:33:40PM -0700, Linus Torvalds wrote:
>> On Mon, 7 Apr 2025 at 14:10, Mark Brown <broonie@kernel.org> wrote:
>
>> > Arnd bisected this to c56f649646ec ("landlock: Log mount-related
>> > denials") but that commit is fairly obviously not really at fault here,
>> > most likely this is an issue in the plugin.  Given how disruptive having
>> > key configs like this failing let's disable the plugins for compile test
>> > builds until a fix is found.
>
>> I'm not against this, but I do want to bring up the "are the plugins
>> worth having at all" discussion again.
>
>> They've been a pain before. Afaik, the actual useful cases are now
>> done by actual real compiler support (and by clang, at that).
>
>> Who actually *uses* the gcc plugins? They just worry me in general,
>> and this is not the first time they have caused ICE problems.
>
> There was a bit of discussion of that on IRC which didn't summon up huge
> enthusiasm for them.  Arnd noted that:
>
>     https://github.com/nyrahul/linux-kernel-configs
>
> indicates that Talos 1.9.1 uses latent_entropy (but we didn't check how
> accurate that survey is).

Talos also uses stackleak. I also see that alpine and qubes have the
same two gcc plugins enabled.

On the other hand none of the other 60 distros on that list use any
plugins, and most of those kernels appear to be built with a compiler
that doesn't support plugins. A few notable ones (Arch, Fedora
CoreOS 35, RHEL 9) in the list have CONFIG_GCC_PLUGINS=y but then
don't enable any of them.

>  He also noted that GCC_PLUGIN_SANCOV is
> obsolete as of GCC 6 (!) and both CC_HAVE_STACKPROTECTOR_TLS and
> GCC_PLUGIN_STRUCTLEAK_BYREF_ALL as of GCC 12, Ard indicated he wasn't
> worried about loosing CC_HAVE_STACKPROTECTOR_TLS.

I've drafted patches to remove these three now: even if we're
only moving from gcc-5 to gcc-8 as the minimum supported version,
I don't think there is much intersection between users of those
plugins and those that are stuck on gcc-11 or earlier.

      Arnd

Re: [PATCH] gcc-plugins: Disable GCC plugins for compile test builds

[Kees Cook]

On April 8, 2025 2:22:52 AM PDT, Arnd Bergmann <arnd@arndb.de> wrote:
>On Tue, Apr 8, 2025, at 00:02, Mark Brown wrote:
>> On Mon, Apr 07, 2025 at 02:33:40PM -0700, Linus Torvalds wrote:
>>> On Mon, 7 Apr 2025 at 14:10, Mark Brown <broonie@kernel.org> wrote:
>>
>>> > Arnd bisected this to c56f649646ec ("landlock: Log mount-related
>>> > denials") but that commit is fairly obviously not really at fault here,
>>> > most likely this is an issue in the plugin.  Given how disruptive having
>>> > key configs like this failing let's disable the plugins for compile test
>>> > builds until a fix is found.
>>
>>> I'm not against this, but I do want to bring up the "are the plugins
>>> worth having at all" discussion again.
>>
>>> They've been a pain before. Afaik, the actual useful cases are now
>>> done by actual real compiler support (and by clang, at that).
>>
>>> Who actually *uses* the gcc plugins? They just worry me in general,
>>> and this is not the first time they have caused ICE problems.
>>
>> There was a bit of discussion of that on IRC which didn't summon up huge
>> enthusiasm for them.  Arnd noted that:
>>
>>     https://github.com/nyrahul/linux-kernel-configs
>>
>> indicates that Talos 1.9.1 uses latent_entropy (but we didn't check how
>> accurate that survey is).

The early RNG for small machines remains pretty bad, so I can understand wanting to keep that around. For bigger machines it's not as much of a benefit.

>Talos also uses stackleak. I also see that alpine and qubes have the
>same two gcc plugins enabled.

Yeah, stackleak has no viable alternative. It's effectively init_on_free for stack. It's be nice if there were a way to do this with upstream compilers (track call depth).

>On the other hand none of the other 60 distros on that list use any
>plugins, and most of those kernels appear to be built with a compiler
>that doesn't support plugins. A few notable ones (Arch, Fedora
>CoreOS 35, RHEL 9) in the list have CONFIG_GCC_PLUGINS=y but then
>don't enable any of them.
>
>>  He also noted that GCC_PLUGIN_SANCOV is
>> obsolete as of GCC 6 (!) and both CC_HAVE_STACKPROTECTOR_TLS and
>> GCC_PLUGIN_STRUCTLEAK_BYREF_ALL as of GCC 12, Ard indicated he wasn't
>> worried about loosing CC_HAVE_STACKPROTECTOR_TLS.
>
>I've drafted patches to remove these three now: even if we're
>only moving from gcc-5 to gcc-8 as the minimum supported version,
>I don't think there is much intersection between users of those
>plugins and those that are stuck on gcc-11 or earlier.

I have no problem removing sanconv (no longer needed), structleak (zero-init is more complete), and stackprot-tls (assuming it really is supported after GCC 12?)

-Kees

-- 
Kees Cook

Re: [PATCH] gcc-plugins: Disable GCC plugins for compile test builds

[Arnd Bergmann]

On Tue, Apr 8, 2025, at 22:37, Kees Cook wrote:
> On April 8, 2025 2:22:52 AM PDT, Arnd Bergmann <arnd@arndb.de> wrote:
>>>
>>> indicates that Talos 1.9.1 uses latent_entropy (but we didn't check how
>>> accurate that survey is).
>
> The early RNG for small machines remains pretty bad, so I can 
> understand wanting to keep that around. For bigger machines it's not as 
> much of a benefit.

Does "small machines" still mean those without a cycle counter
as in the 2009 article [https://phrack.org/issues/66/15#article]
or are you thinking of those that may have a working
random_get_entropy() but that remains too predictable for
add_device_randomness() because of the low frequency (e.g.
19.2 MHz on many ARMv7/v8)?

The former (ARMv5, AMD Elan, Xburst) were still common back then
but are mostly extinct now, while the latter obviously remain
in wide use.

>>Talos also uses stackleak. I also see that alpine and qubes have the
>>same two gcc plugins enabled.
>
> Yeah, stackleak has no viable alternative. It's effectively 
> init_on_free for stack. It's be nice if there were a way to do this 
> with upstream compilers (track call depth).

I guess a simplified version could in theory be done in the kernel
using _mcount without compiler help, but that would be much more
expensive if every function entry has to call it, right?

     Arnd

Re: [PATCH] gcc-plugins: Disable GCC plugins for compile test builds

[Kees Cook]

On Mon, Apr 07, 2025 at 09:57:32PM +0100, Mark Brown wrote:
> In current mainline x86_64 allmodconfig builds done with tuxmake GCC 13
> and GCC 14 toolchains (which are Debian ones packaged up into containers)
> generate ICEs in landlock:
> 
> Event                            | Plugins
> PLUGIN_FINISH_TYPE               | randomize_layout_plugin
> PLUGIN_FINISH_DECL               | randomize_layout_plugin
> PLUGIN_ATTRIBUTES                | latent_entropy_plugin randomize_layout_plugin
> PLUGIN_START_UNIT                | latent_entropy_plugin stackleak_plugin
> PLUGIN_ALL_IPA_PASSES_START      | randomize_layout_plugin
> /build/stage/linux/security/landlock/fs.c: In function ‘hook_file_ioctl_common’:
> /build/stage/linux/security/landlock/fs.c:1745:61: internal compiler error: in c
> ount_type_elements, at expr.cc:7075
>  1745 |                         .u.op = &(struct lsm_ioctlop_audit) {
>       |                                                             ^
> 
> Arnd bisected this to c56f649646ec ("landlock: Log mount-related
> denials") but that commit is fairly obviously not really at fault here,
> most likely this is an issue in the plugin.  Given how disruptive having
> key configs like this failing let's disable the plugins for compile test
> builds until a fix is found.

Looks like this is a randstruct bug. We'll need to disable that one for
now (rather than all plugins).

I can reproduce this for GCC 14, but I can't reproduce this with GCC
13. Which minor release is failing for you? My GCC 13 is:
gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0

-Kees

-- 
Kees Cook

Re: [PATCH] gcc-plugins: Disable GCC plugins for compile test builds

[Arnd Bergmann]

On Wed, Apr 9, 2025, at 01:32, Kees Cook wrote:

> I can reproduce this for GCC 14, but I can't reproduce this with GCC
> 13. Which minor release is failing for you? My GCC 13 is:
> gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0

I see it with "x86_64-linux-gnu-gcc-12 (Debian 12.2.0-14) 12.2.0"
(cross-compiling from arm64).

     Arnd

Re: [PATCH] gcc-plugins: Disable GCC plugins for compile test builds

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 940 bytes --]

On Tue, Apr 08, 2025 at 04:32:24PM -0700, Kees Cook wrote:
> On Mon, Apr 07, 2025 at 09:57:32PM +0100, Mark Brown wrote:

> > Arnd bisected this to c56f649646ec ("landlock: Log mount-related
> > denials") but that commit is fairly obviously not really at fault here,
> > most likely this is an issue in the plugin.  Given how disruptive having
> > key configs like this failing let's disable the plugins for compile test
> > builds until a fix is found.

> Looks like this is a randstruct bug. We'll need to disable that one for
> now (rather than all plugins).

Note that the patch is only disabling for build coverage builds where
the resulting binaries generally aren't going to actually be run.

> I can reproduce this for GCC 14, but I can't reproduce this with GCC
> 13. Which minor release is failing for you? My GCC 13 is:
> gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0

Should have been x86_64-linux-gnu-gcc (Debian 13.3.0-5) 13.3.0.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] gcc-plugins: Disable GCC plugins for compile test builds

[Linus Torvalds]

On Wed, 9 Apr 2025 at 05:20, Mark Brown <broonie@kernel.org> wrote:
>
> Note that the patch is only disabling for build coverage builds where
> the resulting binaries generally aren't going to actually be run.

Well, there's a reason we do build coverage - we also want to test
that the non-build coverage case builds.

And it's not actually obvious that it does - it's in fact rather
likely that the gcc plugin is broken in general, and it just so
happens that it's the build bots that find it.

Which is why I honestly would prefer to just disable the plugins in general.

Because the problem is the plugin, not the build coverage.

             Linus

Re: [PATCH] gcc-plugins: Disable GCC plugins for compile test builds

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]

On Wed, Apr 09, 2025 at 08:33:03AM -0700, Linus Torvalds wrote:
> On Wed, 9 Apr 2025 at 05:20, Mark Brown <broonie@kernel.org> wrote:

> > Note that the patch is only disabling for build coverage builds where
> > the resulting binaries generally aren't going to actually be run.

> Well, there's a reason we do build coverage - we also want to test
> that the non-build coverage case builds.

> And it's not actually obvious that it does - it's in fact rather
> likely that the gcc plugin is broken in general, and it just so
> happens that it's the build bots that find it.

Sadly it seems like the build bots didn't find it, or at least if they
found it they didn't identify it well enough to end up with reporting
the issue to someone who'd fix it.  I ran into it because I do
allmodconfig builds as part of applying things since both you and
Stephen do them and that exploded in my face at -rc1.

> Which is why I honestly would prefer to just disable the plugins in general.

> Because the problem is the plugin, not the build coverage.

Well, yes.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] gcc-plugins: Disable GCC plugins for compile test builds

[Linus Torvalds]

On Wed, 9 Apr 2025 at 10:29, Mark Brown <broonie@kernel.org> wrote:
>
> Sadly it seems like the build bots didn't find it, or at least if they
> found it they didn't identify it well enough to end up with reporting
> the issue to someone who'd fix it.

I wouldn't be entirely surpised if a lot of the build bots end up
running old distros (because "enterprise").

So this is presumably only happening with certain compiler versions,
and I expect the build bots have a fairly small set of compilers they
end up testing.

            Linus

Re: [PATCH] gcc-plugins: Disable GCC plugins for compile test builds

[Kees Cook]

On Wed, Apr 09, 2025 at 10:42:19AM -0700, Linus Torvalds wrote:
> On Wed, 9 Apr 2025 at 10:29, Mark Brown <broonie@kernel.org> wrote:
> >
> > Sadly it seems like the build bots didn't find it, or at least if they
> > found it they didn't identify it well enough to end up with reporting
> > the issue to someone who'd fix it.
> 
> I wouldn't be entirely surpised if a lot of the build bots end up
> running old distros (because "enterprise").
> 
> So this is presumably only happening with certain compiler versions,
> and I expect the build bots have a fairly small set of compilers they
> end up testing.

I'm still trying to figure out what the matrix is, because I can
reproduce the crash on Debian's GCC 12 but not Ubuntu's GCC 13, etc.
It feels like there are a few corner cases involved here. So it's
not just the regular "new compiler changes" that usually break the
plugins. Regardless, I'm still digging...

-- 
Kees Cook

Re: [PATCH] gcc-plugins: Disable GCC plugins for compile test builds

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]

On Wed, Apr 09, 2025 at 10:42:19AM -0700, Linus Torvalds wrote:
> On Wed, 9 Apr 2025 at 10:29, Mark Brown <broonie@kernel.org> wrote:

> > Sadly it seems like the build bots didn't find it, or at least if they
> > found it they didn't identify it well enough to end up with reporting
> > the issue to someone who'd fix it.

> I wouldn't be entirely surpised if a lot of the build bots end up
> running old distros (because "enterprise").

I know bunch of them are running Debian, often with a default GCC of
whatever the base Debian version they're running has at any given time.

> So this is presumably only happening with certain compiler versions,
> and I expect the build bots have a fairly small set of compilers they
> end up testing.

Yeah.  The other problem we have is that AFAIK unlike clang we don't
really have people actively working on GCC coverage specifically,
everyone mostly just assumes everyone else is doing it since GCC is the
default (me being as guilty of that as everyone else here).  The work
Arnd's doing is the nearest thing I'm aware of but that's more
intermittent and I gather his toolchains don't have plugins enabled
which wouldn't help here.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] gcc-plugins: Disable GCC plugins for compile test builds

[Arnd Bergmann]

On Wed, Apr 9, 2025, at 20:09, Mark Brown wrote:
> On Wed, Apr 09, 2025 at 10:42:19AM -0700, Linus Torvalds wrote:
>
> Yeah.  The other problem we have is that AFAIK unlike clang we don't
> really have people actively working on GCC coverage specifically,
> everyone mostly just assumes everyone else is doing it since GCC is the
> default (me being as guilty of that as everyone else here).  The work
> Arnd's doing is the nearest thing I'm aware of but that's more
> intermittent and I gather his toolchains don't have plugins enabled
> which wouldn't help here.

Right, I don't think there is any sensible way to support plugins
with my cross compilers, because that requires building the plugin
on a developer's machine and link it against the compiler I statically
linked against a specific libstdc++ to avoid runtime compatibility
problems.

       Arnd

Re: [PATCH] gcc-plugins: Disable GCC plugins for compile test builds

[Palmer Dabbelt]

On Mon, 07 Apr 2025 13:57:32 PDT (-0700), broonie@kernel.org wrote:
> In current mainline x86_64 allmodconfig builds done with tuxmake GCC 13
> and GCC 14 toolchains (which are Debian ones packaged up into containers)
> generate ICEs in landlock:
>
> Event                            | Plugins
> PLUGIN_FINISH_TYPE               | randomize_layout_plugin
> PLUGIN_FINISH_DECL               | randomize_layout_plugin
> PLUGIN_ATTRIBUTES                | latent_entropy_plugin randomize_layout_plugin
> PLUGIN_START_UNIT                | latent_entropy_plugin stackleak_plugin
> PLUGIN_ALL_IPA_PASSES_START      | randomize_layout_plugin
> /build/stage/linux/security/landlock/fs.c: In function ‘hook_file_ioctl_common’:
> /build/stage/linux/security/landlock/fs.c:1745:61: internal compiler error: in c
> ount_type_elements, at expr.cc:7075
>  1745 |                         .u.op = &(struct lsm_ioctlop_audit) {
>       |                                                             ^
>
> Arnd bisected this to c56f649646ec ("landlock: Log mount-related
> denials") but that commit is fairly obviously not really at fault here,
> most likely this is an issue in the plugin.  Given how disruptive having
> key configs like this failing let's disable the plugins for compile test
> builds until a fix is found.
>
> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  scripts/gcc-plugins/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/scripts/gcc-plugins/Kconfig b/scripts/gcc-plugins/Kconfig
> index e383cda05367..29b03c136165 100644
> --- a/scripts/gcc-plugins/Kconfig
> +++ b/scripts/gcc-plugins/Kconfig
> @@ -7,6 +7,7 @@ config HAVE_GCC_PLUGINS
>
>  menuconfig GCC_PLUGINS
>  	bool "GCC plugins"
> +	depends on !COMPILE_TEST
>  	depends on HAVE_GCC_PLUGINS
>  	depends on CC_IS_GCC
>  	depends on $(success,test -e $(shell,$(CC) -print-file-name=plugin)/include/plugin-version.h)
>
> ---
> base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8
> change-id: 20250407-kbuild-disable-gcc-plugins-8701aa609cb3
>
> Best regards,

This one's been biting me too.  It manifests for me on gcc-12 and gcc-13 
(both locally built toolchains off the release branches, cross compiling 
for RISC-V).

Tested-by: Palmer Dabbelt <palmer@rivosinc.com>

Re: [PATCH] gcc-plugins: Disable GCC plugins for compile test builds

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

On Tue, Apr 15, 2025 at 01:26:34PM -0700, Palmer Dabbelt wrote:
> On Mon, 07 Apr 2025 13:57:32 PDT (-0700), broonie@kernel.org wrote:

> > In current mainline x86_64 allmodconfig builds done with tuxmake GCC 13
> > and GCC 14 toolchains (which are Debian ones packaged up into containers)
> > generate ICEs in landlock:

> This one's been biting me too.  It manifests for me on gcc-12 and gcc-13
> (both locally built toolchains off the release branches, cross compiling for
> RISC-V).

> Tested-by: Palmer Dabbelt <palmer@rivosinc.com>

Kees has a narrower workaround for this:

    https://lore.kernel.org/all/20250409151154.work.872-kees@kernel.org/

It's in -next but not pending-fixes, I'm not sure what the plan is for
getting this into mainline - Kees?  The commit log mentions getting it
in for -rc2 so I think the plan is to merge it as a fix.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] gcc-plugins: Disable GCC plugins for compile test builds

[Kees Cook]

On Tue, Apr 15, 2025 at 09:41:06PM +0100, Mark Brown wrote:
> On Tue, Apr 15, 2025 at 01:26:34PM -0700, Palmer Dabbelt wrote:
> > On Mon, 07 Apr 2025 13:57:32 PDT (-0700), broonie@kernel.org wrote:
> 
> > > In current mainline x86_64 allmodconfig builds done with tuxmake GCC 13
> > > and GCC 14 toolchains (which are Debian ones packaged up into containers)
> > > generate ICEs in landlock:
> 
> > This one's been biting me too.  It manifests for me on gcc-12 and gcc-13
> > (both locally built toolchains off the release branches, cross compiling for
> > RISC-V).
> 
> > Tested-by: Palmer Dabbelt <palmer@rivosinc.com>
> 
> Kees has a narrower workaround for this:
> 
>     https://lore.kernel.org/all/20250409151154.work.872-kees@kernel.org/
> 
> It's in -next but not pending-fixes, I'm not sure what the plan is for
> getting this into mainline - Kees?  The commit log mentions getting it
> in for -rc2 so I think the plan is to merge it as a fix.

Yeah, I missed -rc2, and will send it to Linus for -rc3 (with other
stuff) probably tomorrow.

-- 
Kees Cook

Re: [PATCH] gcc-plugins: Disable GCC plugins for compile test builds

[Kees Cook]

On Tue, Apr 15, 2025 at 01:26:34PM -0700, Palmer Dabbelt wrote:
> On Mon, 07 Apr 2025 13:57:32 PDT (-0700), broonie@kernel.org wrote:
> > In current mainline x86_64 allmodconfig builds done with tuxmake GCC 13
> > and GCC 14 toolchains (which are Debian ones packaged up into containers)
> > generate ICEs in landlock:
> > 
> > Event                            | Plugins
> > PLUGIN_FINISH_TYPE               | randomize_layout_plugin
> > PLUGIN_FINISH_DECL               | randomize_layout_plugin
> > PLUGIN_ATTRIBUTES                | latent_entropy_plugin randomize_layout_plugin
> > PLUGIN_START_UNIT                | latent_entropy_plugin stackleak_plugin
> > PLUGIN_ALL_IPA_PASSES_START      | randomize_layout_plugin
> > /build/stage/linux/security/landlock/fs.c: In function ‘hook_file_ioctl_common’:
> > /build/stage/linux/security/landlock/fs.c:1745:61: internal compiler error: in c
> > ount_type_elements, at expr.cc:7075
> >  1745 |                         .u.op = &(struct lsm_ioctlop_audit) {
> >       |                                                             ^
> > 
> > Arnd bisected this to c56f649646ec ("landlock: Log mount-related
> > denials") but that commit is fairly obviously not really at fault here,
> > most likely this is an issue in the plugin.  Given how disruptive having
> > key configs like this failing let's disable the plugins for compile test
> > builds until a fix is found.
> > 
> > Suggested-by: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Mark Brown <broonie@kernel.org>
> > ---
> >  scripts/gcc-plugins/Kconfig | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/scripts/gcc-plugins/Kconfig b/scripts/gcc-plugins/Kconfig
> > index e383cda05367..29b03c136165 100644
> > --- a/scripts/gcc-plugins/Kconfig
> > +++ b/scripts/gcc-plugins/Kconfig
> > @@ -7,6 +7,7 @@ config HAVE_GCC_PLUGINS
> > 
> >  menuconfig GCC_PLUGINS
> >  	bool "GCC plugins"
> > +	depends on !COMPILE_TEST
> >  	depends on HAVE_GCC_PLUGINS
> >  	depends on CC_IS_GCC
> >  	depends on $(success,test -e $(shell,$(CC) -print-file-name=plugin)/include/plugin-version.h)
> > 
> > ---
> > base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8
> > change-id: 20250407-kbuild-disable-gcc-plugins-8701aa609cb3
> > 
> > Best regards,
> 
> This one's been biting me too.  It manifests for me on gcc-12 and gcc-13
> (both locally built toolchains off the release branches, cross compiling for
> RISC-V).
> 
> Tested-by: Palmer Dabbelt <palmer@rivosinc.com>

Thanks! This is fixed differently in -next:

https://web.git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=for-linus/hardening&id=1ded828affa35f4b216e99f53d8d031a392f2b0a

-- 
Kees Cook