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

[Kees Cook]

On April 8, 2025 2:22:52 AM PDT, Arnd Bergmann <arnd at 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 at 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