linux-kernel - Re: gcc 5 & 6 & others already out of date?

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: <Y0gteD0QYVlYxSZh@zx2c4.com>
Date:   Thu, 13 Oct 2022 09:23:36 -0600
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     linux-toolchains@...r.kernel.org,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: gcc 5 & 6 & others already out of date?

On Thu, Oct 13, 2022 at 01:59:52PM +0100, Mark Brown wrote:
> The expected users for old toolchains was always users doing something
> like building a newer kernel on an old enterprise distro rather than
> people actually developing anything AIUI.
> Two or three releases seems a bit ambitious, I'm sitting here in front
> of a Debian stable system which probably has another year or so of being
> the latest release left and it's sitting at GCC 10.2 with the latest
> release of GCC being 12.2.  Probably also worth noting that GCC did a
> 9.5 release in May this year as it went out of their support window.
> A quick look suggests that RHEL 7 is at GCC 4.8 (so running into trouble
> anyway), RHEL 8 at 8.x, SLES looks like it makes newer compilers
> available even for the old releases (eg, there's GCCs up to 10 available
> for SLES 12 AFAICT).  Ubuntu 16.04 does seem to use GCC 5 but it's on
> extended security support at this point, their 18.04 is at GCC 7.4 from
> the looks of it.

The thing is, do we really want to be catering to this? In the first
place, enterprise users and enterprise kernels are already doing freaky
things, forked to no end. But moreover, do we actually want to support
people building the kernel with a different compiler than most of us
develop with? In a basic way, that just seems like a recipe for
disaster.

It's also easy, nearly trivial, to download toolchains. Arnd provides a
bunch with his crosstool. "Must use a toolchain from your distro" is a
requirement that affects nobody.

So I just think we're thinking about this all wrong. It doesn't matter
what's available on the distros. It matters what the most reasonable
compiler to develop with is, first of all. And secondly, it matters that
this compiler is easily available for users to download in a variety of
settings need-be. And I'm pretty sure this latter part is already the
case.

Plus, as I mentioned earlier, this is already the model we're going
toward by virtue of Rust (and to a small extent, Clang) invading.

Jason