[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202401251509.17795F434@keescook>
Date: Thu, 25 Jan 2024 15:10:24 -0800
From: Kees Cook <keescook@...omium.org>
To: Nathan Chancellor <nathan@...nel.org>
Cc: akpm@...ux-foundation.org, masahiroy@...nel.org, nicolas@...sle.eu,
linux-kbuild@...r.kernel.org, llvm@...ts.linux.dev,
patches@...ts.linux.dev, linux-kernel@...r.kernel.org,
tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
dave.hansen@...ux.intel.com, x86@...nel.org, linux@...linux.org.uk,
ardb@...nel.org, linux-arm-kernel@...ts.infradead.org,
catalin.marinas@....com, will@...nel.org, mark.rutland@....com,
mpe@...erman.id.au, npiggin@...il.com, aneesh.kumar@...nel.org,
naveen.n.rao@...ux.ibm.com, linuxppc-dev@...ts.ozlabs.org,
paul.walmsley@...ive.com, palmer@...belt.com, aou@...s.berkeley.edu,
conor@...nel.org, linux-riscv@...ts.infradead.org,
linux-hardening@...r.kernel.org
Subject: Re: [PATCH 00/11] Bump the minimum supported version of LLVM to
13.0.1
On Thu, Jan 25, 2024 at 03:55:06PM -0700, Nathan Chancellor wrote:
> Hi all,
>
> This series bumps the minimum supported version of LLVM for building the
> kernel to 13.0.1. The first patch does the bump and all subsequent
> patches clean up all the various workarounds and checks for earlier
> versions.
>
> Quoting the first patch's commit message for those that were only on CC
> for the clean ups:
>
> When __builtin_mul_overflow() has arguments that differ in terms of
> signedness and width, LLVM may generate a libcall to __muloti4 because
> it performs the checks in terms of 65-bit multiplication. This issue
> becomes harder to hit (but still possible) after LLVM 12.0.0, which
> includes a special case for matching widths but different signs.
>
> To gain access to this special case, which the kernel can take advantage
> of when calls to __muloti4 appear, bump the minimum supported version of
> LLVM for building the kernel to 13.0.1. 13.0.1 was chosen because there
> is minimal impact to distribution support while allowing a few more
> workarounds to be dropped in the kernel source than if 12.0.0 were
> chosen. Looking at container images of up to date distribution versions:
>
> archlinux:latest clang version 16.0.6
> debian:oldoldstable-slim clang version 7.0.1-8+deb10u2 (tags/RELEASE_701/final)
> debian:oldstable-slim Debian clang version 11.0.1-2
> debian:stable-slim Debian clang version 14.0.6
> debian:testing-slim Debian clang version 16.0.6 (19)
> debian:unstable-slim Debian clang version 16.0.6 (19)
> fedora:38 clang version 16.0.6 (Fedora 16.0.6-3.fc38)
> fedora:latest clang version 17.0.6 (Fedora 17.0.6-1.fc39)
> fedora:rawhide clang version 17.0.6 (Fedora 17.0.6-1.fc40)
> opensuse/leap:latest clang version 15.0.7
> opensuse/tumbleweed:latest clang version 17.0.6
> ubuntu:focal clang version 10.0.0-4ubuntu1
> ubuntu:latest Ubuntu clang version 14.0.0-1ubuntu1.1
> ubuntu:rolling Ubuntu clang version 16.0.6 (15)
> ubuntu:devel Ubuntu clang version 17.0.6 (3)
>
> The only distribution that gets left behind is Debian Bullseye, as the
> default version is 11.0.1; other distributions either have a newer
> version than 13.0.1 or one older than the current minimum of 11.0.0.
> Debian has easy access to more recent LLVM versions through
> apt.llvm.org, so this is not as much of a concern. There are also the
> kernel.org LLVM toolchains, which should work with distributions with
> glibc 2.28 and newer.
>
> Another benefit of slimming up the number of supported versions of LLVM
> for building the kernel is reducing the build capacity needed to support
> a matrix that builds with each supported version, which allows a matrix
> to reallocate the freed up build capacity towards something else, such
> as more configuration combinations.
>
> This passes my build matrix with all supported versions.
>
> This is based on Andrew's mm-nonmm-unstable to avoid trivial conflicts
> with my series to update the LLVM links across the repository [1] but I
> can easily rebase it to linux-kbuild if Masahiro would rather these
> patches go through there (and defer the conflict resolution to the merge
> window).
>
> [1]: https://lore.kernel.org/20240109-update-llvm-links-v1-0-eb09b59db071@kernel.org/
>
> ---
> Nathan Chancellor (11):
> kbuild: Raise the minimum supported version of LLVM to 13.0.1
> Makefile: Drop warn-stack-size plugin opt
> x86: Drop stack-alignment plugin opt
> ARM: Remove Thumb2 __builtin_thread_pointer workaround for Clang
> arm64: Kconfig: Clean up tautological LLVM version checks
> powerpc: Kconfig: Remove tautology in CONFIG_COMPAT
> riscv: Remove MCOUNT_NAME workaround
> riscv: Kconfig: Remove version dependency from CONFIG_CLANG_SUPPORTS_DYNAMIC_FTRACE
> fortify: Drop Clang version check for 12.0.1 or newer
> lib/Kconfig.debug: Update Clang version check in CONFIG_KCOV
> compiler-clang.h: Update __diag_clang() macros for minimum version bump
>
> Documentation/process/changes.rst | 2 +-
> Makefile | 8 --------
> arch/arm/include/asm/current.h | 8 +-------
> arch/arm64/Kconfig | 5 +----
> arch/powerpc/Kconfig | 1 -
> arch/riscv/Kconfig | 2 --
> arch/riscv/include/asm/ftrace.h | 14 ++------------
> arch/riscv/kernel/mcount.S | 10 +++++-----
> arch/x86/Makefile | 6 ------
> include/linux/compiler-clang.h | 8 ++------
> lib/Kconfig.debug | 2 +-
> scripts/min-tool-version.sh | 2 +-
> scripts/recordmcount.pl | 2 +-
> security/Kconfig | 2 --
> 14 files changed, 15 insertions(+), 57 deletions(-)
> ---
> base-commit: 979741ebd48f75ed6d101c7290e3325340d361ff
> change-id: 20240124-bump-min-llvm-ver-to-13-0-1-39f84dd36b19
>
> Best regards,
> --
> Nathan Chancellor <nathan@...nel.org>
>
Yes, please. :) This looks reasonable -- I appreciate the review of
default Clang versions across distros!
Reviewed-by: Kees Cook <keescook@...omium.org>
--
Kees Cook
Powered by blists - more mailing lists