netdev - Re: mainline build failure due to 281d0c962752 ("fortify: Add Clang support")

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 22 Jun 2022 11:21:09 -0500
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Nathan Chancellor <nathan@...nel.org>
Cc:     Sudip Mukherjee <sudipm.mukherjee@...il.com>,
        Kees Cook <keescook@...omium.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Netdev <netdev@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: mainline build failure due to 281d0c962752 ("fortify: Add Clang support")

On Wed, Jun 22, 2022 at 10:02 AM Nathan Chancellor <nathan@...nel.org> wrote:
>
> Right, we are working on a statically linked and optimized build of LLVM
> that people can use similar to the GCC builds provided on kernel.org,
> which should make the compile time problem not as bad as well as making
> it easier for developers to get access to a recent version of clang with
> all the fixes and improvements that we have made in upstream LLVM.

So I'm on the road, and will try to see how well I can do that
allmodconfig build on my poor laptop and see what else goes wrong for
now.

But I do have to say that it's just a lot better if the regular distro
compiler build works out of the box. I did build my own clang binary
for a while, just because I was an early adopter of the whole "ask
goto with outputs" thing, but I've been *so* much happier now that I
don't need to do that any more.

So I would prefer not going backwards.

I wish the standard clang build just stopped doing the crazy shared
library thing. The security arguments for it are just ridiculous, when
any shared library update for any security reason would mean a full
clang update _anyway_.

I realize it's partly distro rules too, but the distros only do that
"we always build shared libraries" when the project itself makes that
an option. And it's a really stupid option for the regular C compiler
case.

Side note: I think gcc takes almost exactly the opposite approach, and
does much better as a result. It doesn't do a shared libary, but what
it *does* do is make 'gcc' itself a reasonably small binary that just
does the command line front-end parsing.

The advantage of the gcc model is that it works *really* well for the
"test compiler options" kind of stage, where you only run that much
simpler 'gcc' wrapper binary.

We don't actually take full advantage of that, because we do end up
doing a real "build" of an empty file, so "cc1" does actually get
executed, but even then it's done fairly efficiently with 'vfork()'.
That "cc-option" part of the kernel build is actually noticeable
during configuration etc, and clang is *much* slower because of how it
is built.

See

    time clang -Werror -c -x c /dev/null

and compare it with gcc. And if you want to see a really *big*
difference, pick a command line option that causes an error because it
doesn't exist..

I really wish clang wasn't so much noticeably slower. It's limiting
what I do with it, and I've had other developers say the same.

              Linus