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

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: <657fd022-4056-4f7f-aaf2-b4bf88fbcb38@app.fastmail.com>
Date: Thu, 10 Apr 2025 09:58:13 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Kees Cook" <kees@...nel.org>, "Mark Brown" <broonie@...nel.org>,
 "Linus Torvalds" <torvalds@...ux-foundation.org>
Cc: 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 22:37, Kees Cook wrote:
> On April 8, 2025 2:22:52 AM PDT, Arnd Bergmann <arnd@...db.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