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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 22 Jun 2022 08:01:57 -0700
From:   Nathan Chancellor <nathan@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.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")

Hi Linus,

On Wed, Jun 22, 2022 at 08:47:22AM -0500, Linus Torvalds wrote:
> On Wed, Jun 22, 2022 at 5:23 AM Sudip Mukherjee
> <sudipm.mukherjee@...il.com> wrote:
> >
> > I have recently (since yesterday) started building the mainline kernel
> > with clang-14 and I am seeing a build failure with allmodconfig.

Right, this is known. Kees sent a fix for that warning recently but it
went to net-next instead of net it seems:

https://git.kernel.org/netdev/net-next/c/2c0ab32b73cfe39a609192f338464e948fc39117

I am not sure if that change could be cherry-picked or applied to net so
that it could be fixed in mainline, I see the netdev maintainers are
already on CC so maybe they can comment on that?

> Yeah, the clang build has never been allmodconfig-clean, although I
> think it's starting to get pretty close.

Right, we are almost there with ARCH=arm64 and ARCH=x86_64. Both arm64
and x86_64 suffer from the warning that Sudip reported and arm64 grew a
new warning this release from commit 274d79e51875 ("ASoC: Intel: avs:
Configure modules according to their type"):

  sound/soc/intel/avs/path.c:815:18: error: stack frame size (2176) exceeds limit (2048) in 'avs_path_create' [-Werror,-Wframe-larger-than]
  struct avs_path *avs_path_create(struct avs_dev *adev, u32 dma_id,
                   ^
  1 error generated.

I haven't fully figured out what is going wrong with this one, I did
write some analysis on our bug tracker if anyone is curious:

https://github.com/ClangBuiltLinux/linux/issues/1642#issuecomment-1156815611

With those two warnings fixed, arm64 and x86_64 allmodconfig become
-Werror clean with clang-11 through clang-15 on mainline; 5.15 is
already there.

Other architectures aren't that far behind either, ARCH=arm is the worst
one because of KASAN, which has been brought up a few times before
without any real resolution.

> I build the kernel I actually _use_ with clang, and make sure it's
> clean in sane configurations, but my full allmodconfig build I do with
> gcc.
> 
> Partly because of that "the clang build hasn't quite gotten there yet"
> and partly because last I tried it was even slower to build (not a big
> issue for my default config, but does matter for the allmodconfig
> build, even on my beefy home machine)
> 
> I would love for people to start doing allmodconfig builds with clang
> too, but it would require some initial work to fix it... Hint, hint.

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.

> And in the case of this warning attribute case, the clang error messages are
> 
>  (a) verbose
> 
>  (b) useless
> 
> because they point to where the warning attribute is (I know where it
> is), but don't point to where it's actually triggering (ie where it
> was actually inlined and called from).
> 
> The gcc equivalent of that warning actually says exactly where the
> problem is. The clang one is useless, which is probably part of why
> people aren't fixing them, because even if they would want to, they
> just give up.
> 
> Nick, Nathan, any chance of getting better error messages out of
> clang? In some cases, they are very good, so it's not like clang does
> bad error messages by default. But in this case, the error message
> really is *entirely* useless.

Right, known papercut :( Kees also noticed this and reported it on our
issue tracker:

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

I don't do as much on the LLVM side as Nick so I'll let him comment on
how feasible implementing that in clang will be, he already has some
comments on the issue tracker there.

Cheers,
Nathan