linux-kernel - Re: [PATCH v4 00/16] x86-64: Stack protector and percpu improvements

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: <d82bebfc-3eaa-406d-8ea6-22113da30ed5@app.fastmail.com>
Date: Sat, 23 Mar 2024 23:55:02 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Linus Torvalds" <torvalds@...ux-foundation.org>,
 "Brian Gerst" <brgerst@...il.com>
Cc: "Uros Bizjak" <ubizjak@...il.com>, linux-kernel@...r.kernel.org,
 x86@...nel.org, "Ingo Molnar" <mingo@...nel.org>,
 "Thomas Gleixner" <tglx@...utronix.de>, "Borislav Petkov" <bp@...en8.de>,
 "H. Peter Anvin" <hpa@...or.com>, "David Laight" <David.Laight@...lab.com>,
 "Ard Biesheuvel" <ardb@...nel.org>, "Kees Cook" <keescook@...omium.org>,
 "Nathan Chancellor" <nathan@...nel.org>
Subject: Re: [PATCH v4 00/16] x86-64: Stack protector and percpu improvements

On Sat, Mar 23, 2024, at 17:16, Linus Torvalds wrote:
>
> That said, we don't actually have all that many gcc version checks
> around any more, so I think the jump to 5.1 got rid of the worst of
> the horrors. Most of the GCC_VERSION checks are either in gcc-plugins
> (which we should just remove, imnsho - not the version checks, the
> plugins entirely), or for various random minor details (warnign
> enablement and the asm goto workaround).

There are also a bunch of feature checks in Kconfig that don't
check the version number but instead try if something works.

At least three of the six plugins can be removed with sufficiently
new compilers: GCC_PLUGIN_SANCOV after gcc-6, and both
GCC_PLUGIN_STRUCTLEAK and GCC_PLUGIN_ARM_SSP_PER_TASK after
gcc-12.

> So there doesn't seem to be a major reason to up the versioning, since
> the stack protector thing can just be disabled for older versions.
>
> But maybe even enterprise distros have upgraded anyway, and we should
> be proactive.
>
> Cc'ing Arnd, who has historically been one of the people pushing this.
> He may no longer care because we haven't had huge issues.

I'm not aware of any major issues, but it keeps coming up and
a number of people have asked me about it because of smaller
ones. Unfortunately I didn't write down what the problems
were.

I think based on what compiler versions are shipped
by LTS distros, gcc-8.1 is the next logical step when we
do it, covering Debian 10, RHEL 8 and Ubuntu 20.04, which
are probably the oldest we still need to support.

RHEL 7 and SLES 12 are still technically supported distros
as well, but those shipped with gcc-4.8, so we dropped them
in 2020 with the move to gcc-4.9.

So in short, not a lot to gain or lose from raising the
minimum to 8.1, but it would be nice to reduce the possible
test matrix from 10 gcc versions back to the 7 we had in
the past, as well as clean up a few version dependencies.
Similarly we can probably raise the oldest binutils version
to 2.30, as that seems to be the earliest version that was
paired with gcc-8 (in RHEL-8).

     Arnd