lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <08393aa3-05a3-4e3f-8004-f374a3ec4b7e@app.fastmail.com>
Date: Tue, 08 Apr 2025 11:22:52 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Mark Brown" <broonie@...nel.org>,
 "Linus Torvalds" <torvalds@...ux-foundation.org>
Cc: "Kees Cook" <kees@...nel.org>,
 Mickaël Salaün <mic@...ikod.net>,
 Günther Noack <gnoack@...gle.com>,
 linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-security-module@...r.kernel.org, "Ard Biesheuvel" <ardb@...nel.org>
Subject: Re: [PATCH] gcc-plugins: Disable GCC plugins for compile test builds

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@...nel.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ