linux-kernel - Re: [PATCH] Restore gcc check in mips asm/unroll.h

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] [day] [month] [year] [list]

Message-ID: <20200711031623.GA4441@Ryzen-9-3900X.localdomain>
Date:   Fri, 10 Jul 2020 20:16:23 -0700
From:   Nathan Chancellor <natechancellor@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Nick Desaulniers <ndesaulniers@...gle.com>,
        Cesar Eduardo Barros <cesarb@...arb.eti.br>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        clang-built-linux@...glegroups.com
Subject: Re: [PATCH] Restore gcc check in mips asm/unroll.h

On Fri, Jul 10, 2020 at 03:31:00PM -0700, Linus Torvalds wrote:
> On Fri, Jul 10, 2020 at 11:43 AM Nick Desaulniers
> <ndesaulniers@...gle.com> wrote:
> >
> > What I'd really like to see as a policy in the kernel going forward in
> > that ANY new commit that adds some hack or workaround for a specific
> > compiler version add a comment about which toolchain version was
> > problematic, that way when we drop support for that version years
> > later, we can drop whatever hacks and technical debt we've accumulated
> > to support that older version.
> 
> The problem is that at the time we find and fix things, it's often
> _very_ unclear which compiler versions are affected.
> 
> We also have the situation that a lot of distro compilers aren't
> necessarily completely "clean" versions, particularly for the
> "enterprise" ones that get stuck on some old version and then fix up
> their breakage by backporting fixes.

Indeed. I would say this is less common for most distributions with
clang, where they tend to stick closer to tip of tree, but it can still
happen. I guess there is not a really good solution for this but we
could just have a policy that as soon as you move away from the upstream
version, you are on your own.

> When it's some particular version of a compiler that supports a
> particular feature, that tends to be much more straightforward. But
> we've had bugs where it was very unclear when exactly the bug was
> fixed (fi it was fixed at all by the time we do the workaround).

As for putting a seal of approval on a minimum supported version of
LLVM/clang, I have my reservations. 0day keeps uncovering various issues
with its builds and clang's release model is different than from GCC's
so if we ever come across a compiler bug in an older version of clang,
we have basically no hope for getting it fixed. GCC supports older
series through bug fix releases for quite some time (GCC 7 was supported
for two and a half years), whereas with clang, they only see one
servicing release before the next major release (for example, clang
9.0.1 before clang 10.0.0) so it makes getting compiler fixes into the
hands of users much more difficult. I am trying to rectify that with
clang 10 though, where I have been testing that release against a bunch
of different configs both in tree and out of tree:
https://github.com/nathanchance/llvm-kernel-testing

However, I think at this point, we can say clang itself is in a good
position as of clang 9, certainly clang 10. I am less confident in
placing a minimum version on the LLVM tools such as lld though. For arm,
arm64, and x86_64, we are in fairly good shape as of clang 10 but I
think there is probably some more work/polishing to be done there; for
other architectures, it is worse. I suppose we would have to consider
the support model: under what cases is it acceptable to bump the minimum
required version versus inserting a bad compiler hack? As someone who is
not super familiar with the relationship between GCC and the kernel, it
appears to me that the general attitude towards compiler bugs has been
workaround it in the kernel while hoping that it gets fixed at some
point in GCC. We have been pretty aggressive about fixing the compiler
instead of inserting a workaround, which I feel like is the better
solution, but it makes supporting multiple versions of the compiler more
difficult (versus just saying use the latest). It is something that
needs to be discussed and agreed upon sooner rather than later though,
especially as we grow more and more polished.

There were some other thoughts that I had on our issue tracker here, if
anyone cares for them:

https://github.com/ClangBuiltLinux/linux/issues/941

Sorry for the brain dump and cheers,
Nathan