linux-kernel - Re: [PATCH] Makefile: Fix build with scan-build

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: <YeiAa/eCxVZC+QbS@archlinux-ax161>
Date:   Wed, 19 Jan 2022 14:19:39 -0700
From:   Nathan Chancellor <nathan@...nel.org>
To:     Amadeusz Sławiński 
        <amadeuszx.slawinski@...ux.intel.com>
Cc:     linux-kbuild@...r.kernel.org,
        Masahiro Yamada <masahiroy@...nel.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        linux-kernel@...r.kernel.org, llvm@...ts.linux.dev,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Cezary Rojewski <cezary.rojewski@...el.com>
Subject: Re: [PATCH] Makefile: Fix build with scan-build

On Wed, Jan 19, 2022 at 02:51:47PM +0100, Amadeusz Sławiński wrote:
> When building kernel with scan-build for analysis:
> $ scan-build make defconfig
> $ scan-build make menuconfig # disable RETPOLINE
> $ scan-build make -j16 bindeb-pkg
> since commit 7d73c3e9c514 ("Makefile: remove stale cc-option checks")
> it fails with:
>   CC      scripts/mod/empty.o
> could not find clang line
> make[4]: *** [scripts/Makefile.build:287: scripts/mod/empty.o] Error 1
> 
> Seems like changes to how -fconserve-stack support was detected broke
> build with scan-build. Revert part of mentioned commit which changed
> that.
> 
> Fixes: 7d73c3e9c514 ("Makefile: remove stale cc-option checks")
> CC: Nick Desaulniers <ndesaulniers@...gle.com>
> Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@...ux.intel.com>
> Reviewed-by: Cezary Rojewski <cezary.rojewski@...el.com>
> ---
>  Makefile | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 765115c99655..1174ccd182f5 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -991,9 +991,7 @@ KBUILD_CFLAGS	+= -fno-strict-overflow
>  KBUILD_CFLAGS  += -fno-stack-check
>  
>  # conserve stack if available
> -ifdef CONFIG_CC_IS_GCC
> -KBUILD_CFLAGS   += -fconserve-stack
> -endif
> +KBUILD_CFLAGS   += $(call cc-option,-fconserve-stack)
>  
>  # Prohibit date/time macros, which would make the build non-deterministic
>  KBUILD_CFLAGS   += -Werror=date-time
> -- 
> 2.25.1
> 

Okay, I think I understand why this happens...

scan-build points CC to its CC wrapper [1], ccc-analyzer, which builds the
code with a compiler [2] then runs clang for the static analyzer [3].
The problem is that the default compiler for ccc-analyzer is GCC, which
means that CONFIG_CC_IS_GCC gets set and flags that are supported by GCC
but not clang will cause the clang analyzer part of ccc-analyzer to
error because ccc-analyzer just passes all '-f' flags along [4].

Prior to 7d73c3e9c514, there was no error because cc-option would run
the flag against ccc-analyzer, which would error out for the reason I
just described, which would prevent the flag from getting added to
KBUILD_CFLAGS.

Now, -fconserve-stack gets passed along to both gcc and clang but clang
does not recognize it and errors out.

This should be fixed in clang, which already has the machinery to
recognize but ignore GCC flags for compatibility reasons (which is
probably how gcc and clang can use the same flags). I have pushed a
patch to Phabricator for review:

https://reviews.llvm.org/D117717

You need to disable CONFIG_RETPOLINE for the same reason but I don't
think working around that in clang is as simple.

Until that fix can proliferate through distributions and such, this is
not an unreasonable workaround (unless Masahiro or Nick have a better
idea) but I would really like a comment so that we can revert this once
that fix is more widely available (it is unlikely that clang will
actually support this option).

[1]: https://github.com/llvm/llvm-project/blob/3062a1469da0569e714aa4634b29345f6d8c874c/clang/tools/scan-build/bin/scan-build#L1080
[2]: https://github.com/llvm/llvm-project/blob/fd0782a37bbf7dd4ece721df92c703a381595661/clang/tools/scan-build/libexec/ccc-analyzer#L457
[3]: https://github.com/llvm/llvm-project/blob/fd0782a37bbf7dd4ece721df92c703a381595661/clang/tools/scan-build/libexec/ccc-analyzer#L783
[4]: https://github.com/llvm/llvm-project/blob/fd0782a37bbf7dd4ece721df92c703a381595661/clang/tools/scan-build/libexec/ccc-analyzer#L661-L665

Cheers,
Nathan