linux-kernel - Re: [GIT PULL] EFI fixes

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: <CAK8P3a1GFjM5-ENf7XL6jjUvRdJhgjzYpSGD5R7TmW6oWEhYRA@mail.gmail.com>
Date:   Thu, 9 Jul 2020 11:30:27 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...en8.de>,
        linux-efi <linux-efi@...r.kernel.org>
Subject: Re: [GIT PULL] EFI fixes

On Wed, Jul 8, 2020 at 8:00 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Wed, Jul 8, 2020 at 9:21 AM Peter Zijlstra <peterz@...radead.org> wrote:
> > >
> > > It's perhaps yet another reason to just skip gcc-4.8 too, since
> > > apparently 4.9 works.
> > >
> > > gcc-4.9 really has a lot of advantages. It's where (I think) gcc
> > > basically supports all C11 things, including _Generic() but also
> > > __auto_type.
> >
> > +1
> >
> > Anybody for nay, or should we just do this?
>
> I'll just do it. Let's see if anybody screams with a good reason. I
> hate the whole "support old compilers", it ends up not only making for
> complex code, it tends to cause these unnecessary kinds of "guys, we
> tested this really well, but that crazy compiler had a very particular
> odd issue, and it wasn't in any test box.

Cool, thanks for changing it, this is clearly a better suited compiler
version. Aside from the added C11 features, this is also where a lot of
the optimizations changed, so code generation is more predictable
if we don't need to worry about gcc-4.8.

On the flip side, gcc-4.8 was used by old enterprise distros that
are still supported (SUSE 12, RHEL 7), whereas gcc-4.9 was only
shipped in Debian Jessie and Android releases that are both
EOL now (Android never moved beyond a buggy gcc-4.9 prerelease
but now uses clang for everything).

I don't see any technical reasons to go even further, but if
something does come up, the users of these Long-term supported
distros would be most impacted by a change:

gcc-4.9: Used in Debian 8 (Jessie), EOL June 2020
gcc-5: Used in Ubuntu 16.04 (Xenial, Mint 18, ...), EOL April 2021
gcc-6: Used in Debian 9 (Stretch), EOL 2022
gcc-7: Used in SLES 15, Ubuntu 18.04 (Bionic, Mint 19, ...)
gcc-8: Used in RHEL-8 (centos, oracle, ...), OpenWRT

The most interesting version to require in the future would be
gcc-7, which IIRC is the point at which we can just use -std=gnu99
or -std=gnu11 instead of -std=gnu89 without running into the
problem with compound literals[1].

       Arnd

[1] https://patchwork.kernel.org/patch/11195831/