Changes in Makefile

1e7857b2 - x86: don't re-generate cpufeaturemasks.h so eagerly

Mon, 31 Mar 2025 21:19:55 +0000

x86: don't re-generate cpufeaturemasks.h so eagerlyIt turns out the code to generate the x86 cpufeaturemasks.h header wasway too aggressive, and would re-generate it whenever the timestamp onthe kernel config file changed.Now, the regular 'make *config' tools are fairly careful to not rewritethe kernel config file unless the contents change, but other usecasesaren't that careful.Michael Kelley reports that 'make-kpkg' ends up doing "make syncconfig"multiple times in prepping to build, and will modify the config file inthe process (and then modify it back, but by then the timestamps havechanged).Jakub Kicinski reports that the netdev CI does something similar in howit generates the config file in multiple steps.In both cases, the config file timestamp updates then cause thecpufeaturemasks.h file to be regenerated, and that in turn then causeslots of unnecessary rebuilds due to all the normal dependencies.Fix it by using our 'filechk' infrastructure in the Makefile to generatethe header file. That will only write a new version of the file if thecontents of the file have actually changed.Fixes: 841326332bcb ("x86/cpufeatures: Generate the header based on build config")Reported-by: Michael Kelley Reported-by: Jakub Kicinski Link: https://lore.kernel.org/all/SN6PR02MB415756D1829740F6E8AC11D1D4D82@SN6PR02MB4157.namprd02.prod.outlook.com/Link: https://lore.kernel.org/all/20250328162311.08134fa6@kernel.org/Cc: Peter Anvin Signed-off-by: Linus Torvalds List of files: /linux-6.15/arch/x86/Makefile

84132633 - x86/cpufeatures: Generate the header based on build config

Wed, 05 Mar 2025 18:47:22 +0000

x86/cpufeatures: Generate the header based on build configIntroduce an AWK script to auto-generate the headerwith required and disabled feature masks based on and the current build config.Thus for any CPU feature with a build config, e.g., X86_FRED, simply add: config X86_DISABLED_FEATURE_FRED def_bool y depends on !X86_FREDto arch/x86/Kconfig.cpufeatures, instead of adding a conditional CPUfeature disable flag, e.g., DISABLE_FRED.Lastly, the generated required and disabled feature masks will be added totheir corresponding feature masks for this particular compile-timeconfiguration. [ Xin: build integration improvements ] [ mingo: Improved changelog and comments ]Signed-off-by: H. Peter Anvin (Intel) Signed-off-by: Xin Li (Intel) Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Ingo Molnar Reviewed-by: Nikolay Borisov Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250305184725.3341760-3-xin@zytor.com List of files: /linux-6.15/arch/x86/Makefile

9b400d17 - kbuild: Introduce Kconfig symbol for linking vmlinux with relocations

Tue, 11 Mar 2025 11:06:19 +0000

kbuild: Introduce Kconfig symbol for linking vmlinux with relocationsSome architectures build vmlinux with static relocations preserved, butstrip them again from the final vmlinux image. Arch specific toolsconsume these static relocations in order to construct relocation tablesfor KASLR.The fact that vmlinux is created, consumed and subsequently updated goesagainst the typical, declarative paradigm used by Make, which is basedon rules and dependencies. So as a first step towards cleaning this up,introduce a Kconfig symbol to declare that the arch wants to consume thestatic relocations emitted into vmlinux. This will be wired up furtherin subsequent patches.Signed-off-by: Ard Biesheuvel Signed-off-by: Masahiro Yamada List of files: /linux-6.15/arch/x86/Makefile

d70da124 - hardening: Enable i386 FORTIFY_SOURCE on Clang 16+

Sat, 08 Mar 2025 04:29:26 +0000

hardening: Enable i386 FORTIFY_SOURCE on Clang 16+The i386 regparm bug exposed with FORTIFY_SOURCE with Clang was fixedin Clang 16[1].Link: https://github.com/llvm/llvm-project/commit/c167c0a4dcdb998affb2756ce76903a12f7d8ca5 [1]Reviewed-by: Nathan Chancellor Link: https://lore.kernel.org/r/20250308042929.1753543-2-kees@kernel.orgSigned-off-by: Kees Cook List of files: /linux-6.15/arch/x86/Makefile

16cb16e0 - x86/build: Remove -ffreestanding on i386 with GCC

Sat, 08 Mar 2025 04:29:25 +0000

x86/build: Remove -ffreestanding on i386 with GCCThe use of -ffreestanding is a leftover that is only needed for certainversions of Clang. Adjust this to be Clang-only. A later patch will makethis a versioned check.Acked-by: Ingo Molnar Reviewed-by: Nathan Chancellor Link: https://lore.kernel.org/r/20250308042929.1753543-1-kees@kernel.orgSigned-off-by: Kees Cook List of files: /linux-6.15/arch/x86/Makefile

f388f60c - x86/cpu: Drop configuration options for early 64-bit CPUs

Wed, 26 Feb 2025 21:37:08 +0000

x86/cpu: Drop configuration options for early 64-bit CPUsThe x86 CPU selection menu is confusing for a number of reasons:When configuring 32-bit kernels, it shows a small number of early 64-bitmicroarchitectures (K8, Core 2) but not the regular generic 64-bit targetthat is the normal default. There is no longer a reason to run 32-bitkernels on production 64-bit systems, so only actual 32-bit CPUs needto be shown here.When configuring 64-bit kernels, the options also pointless as there isno way to pick any CPU from the past 15 years, leaving GENERIC_CPU asthe only sensible choice.Address both of the above by removing the obsolete options and makingall 64-bit kernels run on both Intel and AMD CPUs from any generation.Testing generic 32-bit kernels on 64-bit hardware remains possible,just not building a 32-bit kernel that requires a 64-bit CPU.Signed-off-by: Arnd Bergmann Signed-off-by: Ingo Molnar Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250226213714.4040853-5-arnd@kernel.org List of files: /linux-6.15/arch/x86/Makefile

fc2d5cbe - x86/build: Rework CONFIG_GENERIC_CPU compiler flags

Wed, 26 Feb 2025 21:37:07 +0000

x86/build: Rework CONFIG_GENERIC_CPU compiler flagsBuilding an x86-64 kernel with CONFIG_GENERIC_CPU is documented torun on all CPUs, but the Makefile does not actually pass an -march=argument, instead relying on the default that was used to configurethe toolchain.In many cases, gcc will be configured to -march=x86-64 or -march=k8for maximum compatibility, but in other cases a distribution defaultmay be either raised to a more recent ISA, or set to -march=nativeto build for the CPU used for compilation. This still works in thecase of building a custom kernel for the local machine.The point where it breaks down is building a kernel for anothermachine that is older the the default target. Changing the defaultto -march=x86-64 would make it work reliable, but possibly produceworse code on distros that intentionally default to a newer ISA.To allow reliably building a kernel for either the oldest x86-64CPUs, pass the -march=x86-64 flag to the compiler. This was notpossible in early versions of x86-64 gcc, but works on all currentlysupported versions down to at least gcc-5.Signed-off-by: Arnd Bergmann Signed-off-by: Ingo Molnar Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250226213714.4040853-4-arnd@kernel.org List of files: /linux-6.15/arch/x86/Makefile

80d47def - x86/stackprotector/64: Convert to normal per-CPU variable

Thu, 23 Jan 2025 19:07:39 +0000

x86/stackprotector/64: Convert to normal per-CPU variableOlder versions of GCC fixed the location of the stack protector canaryat %gs:40. This constraint forced the percpu section to be linked atabsolute address 0 so that the canary could be the first data object inthe percpu section. Supporting the zero-based percpu section requiresadditional code to handle relocations for RIP-relative references topercpu data, extra complexity to kallsyms, and workarounds for linkerbugs due to the use of absolute symbols.GCC 8.1 supports redefining where the canary is located, allowing it tobecome a normal percpu variable instead of at a fixed location. Thisremoves the constraint that the percpu section must be zero-based.Signed-off-by: Brian Gerst Signed-off-by: Ingo Molnar Reviewed-by: Ard Biesheuvel Reviewed-by: Uros Bizjak Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250123190747.745588-8-brgerst@gmail.com List of files: /linux-6.15/arch/x86/Makefile

577c134d - x86/stackprotector: Work around strict Clang TLS symbol requirements

Tue, 05 Nov 2024 15:57:46 +0000

x86/stackprotector: Work around strict Clang TLS symbol requirementsGCC and Clang both implement stack protector support based on Thread LocalStorage (TLS) variables, and this is used in the kernel to implement per-taskstack cookies, by copying a task's stack cookie into a per-CPU variable everytime it is scheduled in.Both now also implement -mstack-protector-guard-symbol=, which permits the TLSvariable to be specified directly. This is useful because it will allow tomove away from using a fixed offset of 40 bytes into the per-CPU area onx86_64, which requires a lot of special handling in the per-CPU code and theruntime relocation code.However, while GCC is rather lax in its implementation of this command lineoption, Clang actually requires that the provided symbol name refers to a TLSvariable (i.e., one declared with __thread), although it also permits thevariable to be undeclared entirely, in which case it will use an implicitdeclaration of the right type.The upshot of this is that Clang will emit the correct references to the stackcookie variable in most cases, e.g., 10d: 64 a1 00 00 00 00 mov %fs:0x0,%eax 10f: R_386_32 __stack_chk_guardHowever, if a non-TLS definition of the symbol in question is visible in thesame compilation unit (which amounts to the whole of vmlinux if LTO isenabled), it will drop the per-CPU prefix and emit a load from a bogusaddress.Work around this by using a symbol name that never occurs in C code, and emitit as an alias in the linker script.Fixes: 3fb0fdb3bbe7 ("x86/stackprotector/32: Make the canary into a regular percpu variable")Signed-off-by: Ard Biesheuvel Signed-off-by: Brian Gerst Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor Cc: stable@vger.kernel.orgLink: https://github.com/ClangBuiltLinux/linux/issues/1854Link: https://lore.kernel.org/r/20241105155801.1779119-2-brgerst@gmail.com List of files: /linux-6.15/arch/x86/Makefile

ca627e63 - rust: cfi: add support for CFI_CLANG with Rust

Thu, 12 Sep 2024 19:00:44 +0000

rust: cfi: add support for CFI_CLANG with RustMake it possible to use the Control Flow Integrity (CFI) sanitizer whenRust is enabled. Enabling CFI with Rust requires that CFI is configuredto normalize integer types so that all integer types of the same sizeand signedness are compatible under CFI.Rust and C use the same LLVM backend for code generation, so Rust KCFIis compatible with the KCFI used in the kernel for C. In the case ofFineIBT, CFI also depends on -Zpatchable-function-entry for rewritingthe function prologue, so we set that flag for Rust as well. The flagfor FineIBT requires rustc 1.80.0 or later, so include a Kconfigrequirement for that.Enabling Rust will select CFI_ICALL_NORMALIZE_INTEGERS because the flagis required to use Rust with CFI. Using select rather than `depends on`avoids the case where Rust is not visible in menuconfig due toCFI_ICALL_NORMALIZE_INTEGERS not being enabled. One disadvantage ofselect is that RUST must `depends on` all of the things thatCFI_ICALL_NORMALIZE_INTEGERS depends on to avoid invalid configurations.Alice has been using KCFI on her phone for several months, so it isreasonably well tested on arm64.Signed-off-by: Matthew Maurer Co-developed-by: Alice Ryhl Signed-off-by: Alice Ryhl Reviewed-by: Sami Tolvanen Tested-by: Gatlin Newhouse Acked-by: Kees Cook Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20240801-kcfi-v2-2-c93caed3d121@google.com[ Replaced `!FINEIBT` requirement with `!CALL_PADDING` to prevent a build error on older Rust compilers. Fixed typo. - Miguel ]Signed-off-by: Miguel Ojeda List of files: /linux-6.15/arch/x86/Makefile

d7868550 - x86/rust: support MITIGATION_RETHUNK

Thu, 25 Jul 2024 18:33:20 +0000

x86/rust: support MITIGATION_RETHUNKThe Rust compiler added support for `-Zfunction-return=thunk-extern` [1]in 1.76.0 [2], i.e. the equivalent of `-mfunction-return=thunk-extern`.Thus add support for `MITIGATION_RETHUNK`.Without this, `objtool` would warn if enabled for Rust and already warnsunder IBT builds, e.g.: samples/rust/rust_print.o: warning: objtool: _R...init+0xa5c: 'naked' return found in RETHUNK buildLink: https://github.com/rust-lang/rust/issues/116853 [1]Link: https://github.com/rust-lang/rust/pull/116892 [2]Reviewed-by: Gary Guo Tested-by: Alice Ryhl Tested-by: Benno Lossin Reviewed-by: Thomas Gleixner Link: https://github.com/Rust-for-Linux/linux/issues/945Link: https://lore.kernel.org/r/20240725183325.122827-4-ojeda@kernel.orgSigned-off-by: Miguel Ojeda List of files: /linux-6.15/arch/x86/Makefile

284a3ac4 - x86/rust: support MITIGATION_RETPOLINE

Thu, 25 Jul 2024 18:33:19 +0000

x86/rust: support MITIGATION_RETPOLINESupport `MITIGATION_RETPOLINE` by enabling the target features thatClang does.The existing target feature being enabled was a leftover fromour old `rust` branch, and it is not enough: the target feature`retpoline-external-thunk` only implies `retpoline-indirect-calls`, butnot `retpoline-indirect-branches` (see LLVM's `X86.td`), unlike Clang'sflag of the same name `-mretpoline-external-thunk` which does imply both(see Clang's `lib/Driver/ToolChains/Arch/X86.cpp`).Without this, `objtool` would complain if enabled for Rust, e.g.: rust/core.o: warning: objtool: _R...escape_default+0x13: indirect jump found in RETPOLINE buildIn addition, change the comment to note that LLVM is the one disablingjump tables when retpoline is enabled, thus we do not need to use`-Zno-jump-tables` for Rust here -- see commit c58f2166ab39 ("Introducethe "retpoline" x86 mitigation technique ...") [1]: The goal is simple: avoid generating code which contains an indirect branch that could have its prediction poisoned by an attacker. In many cases, the compiler can simply use directed conditional branches and a small search tree. LLVM already has support for lowering switches in this way and the first step of this patch is to disable jump-table lowering of switches and introduce a pass to rewrite explicit indirectbr sequences into a switch over integers.As well as a live example at [2].These should be eventually enabled via `-Ctarget-feature` when `rustc`starts recognizing them (or via a new dedicated flag) [3].Cc: Daniel Borkmann Link: https://github.com/llvm/llvm-project/commit/c58f2166ab3987f37cb0d7815b561bff5a20a69a [1]Link: https://godbolt.org/z/G4YPr58qG [2]Link: https://github.com/rust-lang/rust/issues/116852 [3]Reviewed-by: Gary Guo Tested-by: Alice Ryhl Tested-by: Benno Lossin Link: https://github.com/Rust-for-Linux/linux/issues/945Link: https://lore.kernel.org/r/20240725183325.122827-3-ojeda@kernel.orgSigned-off-by: Miguel Ojeda List of files: /linux-6.15/arch/x86/Makefile

b0b8a15b - x86: implement ARCH_HAS_KERNEL_FPU_SUPPORT

Fri, 29 Mar 2024 07:18:25 +0000

x86: implement ARCH_HAS_KERNEL_FPU_SUPPORTx86 already provides kernel_fpu_begin() and kernel_fpu_end(), but in adifferent header. Add a wrapper header, and export the CFLAGS adjustmentsas found in lib/Makefile.Link: https://lkml.kernel.org/r/20240329072441.591471-11-samuel.holland@sifive.comSigned-off-by: Samuel Holland Reviewed-by: Christoph Hellwig Acked-by: Christian König Cc: Alex Deucher Cc: Borislav Petkov (AMD) Cc: Catalin Marinas Cc: Dave Hansen Cc: Huacai Chen Cc: Ingo Molnar Cc: Jonathan Corbet Cc: Masahiro Yamada Cc: Michael Ellerman Cc: Nathan Chancellor Cc: Nicolas Schier Cc: Palmer Dabbelt Cc: Russell King Cc: Thomas Gleixner Cc: WANG Xuerui Cc: Will Deacon Signed-off-by: Andrew Morton List of files: /linux-6.15/arch/x86/Makefile

f25eae2c - arch: Select fbdev helpers with CONFIG_VIDEO

Fri, 29 Mar 2024 20:32:10 +0000

arch: Select fbdev helpers with CONFIG_VIDEOVarious Kconfig options selected the per-architecture helpers forfbdev. But none of the contained code depends on fbdev. Standardizeon CONFIG_VIDEO, which will allow to add more general helpers forvideo functionality.CONFIG_VIDEO protects each architecture's video/ directory. Thisallows for the use of more fine-grained control for each directory'sfiles, such as the use of CONFIG_STI_CORE on parisc.v2:- sparc: rebased onto Makefile changesSigned-off-by: Thomas Zimmermann Reviewed-by: Sam Ravnborg Cc: "James E.J. Bottomley" Cc: Helge Deller Cc: "David S. Miller" Cc: Andreas Larsson Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: x86@kernel.orgCc: "H. Peter Anvin" Signed-off-by: Arnd Bergmann List of files: /linux-6.15/arch/x86/Makefile

3f1a9bc5 - x86/build: Use obj-y to descend into arch/x86/virt/

Sat, 30 Mar 2024 06:05:54 +0000

x86/build: Use obj-y to descend into arch/x86/virt/Commit c33621b4c5ad ("x86/virt/tdx: Wire up basic SEAMCALL functions")introduced a new instance of core-y instead of the standardized obj-ysyntax.X86 Makefiles descend into subdirectories of arch/x86/virt inconsistently;into arch/x86/virt/ via core-y defined in arch/x86/Makefile, but intoarch/x86/virt/svm/ via obj-y defined in arch/x86/Kbuild.This is problematic when you build a single object in parallel becausemultiple threads attempt to build the same file. $ make -j$(nproc) arch/x86/virt/vmx/tdx/seamcall.o [ snip ] AS arch/x86/virt/vmx/tdx/seamcall.o AS arch/x86/virt/vmx/tdx/seamcall.o fixdep: error opening file: arch/x86/virt/vmx/tdx/.seamcall.o.d: No such file or directory make[4]: *** [scripts/Makefile.build:362: arch/x86/virt/vmx/tdx/seamcall.o] Error 2Use the obj-y syntax, as it works correctly.Signed-off-by: Masahiro Yamada Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20240330060554.18524-1-masahiroy@kernel.org List of files: /linux-6.15/arch/x86/Makefile

22d3da07 - x86: drop stack-alignment plugin opt

Thu, 25 Jan 2024 22:55:09 +0000

x86: drop stack-alignment plugin optNow that the minimum supported version of LLVM for building the kernel hasbeen bumped to 13.0.1, the inner ifeq statement is always false, as thebuild will fail during the configuration stage for older LLVM versions.This effectively reverts part of commit b33fff07e3e3 ("x86, build: allowLTO to be selected") and its follow up fix, commit 2398ce80152a ("x86,lto: Pass -stack-alignment only on LLD < 13.0.0").Link: https://lkml.kernel.org/r/20240125-bump-min-llvm-ver-to-13-0-1-v1-3-f5ff9bda41c5@kernel.orgSigned-off-by: Nathan Chancellor Reviewed-by: Kees Cook Cc: Albert Ou Cc: "Aneesh Kumar K.V (IBM)" Cc: Ard Biesheuvel Cc: Borislav Petkov (AMD) Cc: Catalin Marinas Cc: Conor Dooley Cc: Dave Hansen Cc: Ingo Molnar Cc: Mark Rutland Cc: Masahiro Yamada Cc: Michael Ellerman Cc: "Naveen N. Rao" Cc: Nicholas Piggin Cc: Nicolas Schier Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Russell King Cc: Thomas Gleixner Cc: Will Deacon Signed-off-by: Andrew Morton List of files: /linux-6.15/arch/x86/Makefile

3b9ab248 - kbuild: use 4-space indentation when followed by conditionals

Fri, 02 Feb 2024 01:31:42 +0000

kbuild: use 4-space indentation when followed by conditionalsGNU Make manual [1] clearly forbids a tab at the beginning of theconditional directive line: "Extra spaces are allowed and ignored at the beginning of the conditional directive line, but a tab is not allowed."This will not work for the next release of GNU Make, hence commit82175d1f9430 ("kbuild: Replace tabs with spaces when followed byconditionals") replaced the inappropriate tabs with 8 spaces.However, the 8-space indentation cannot be visually distinguished.Linus suggested 2-4 spaces for those nested if-statements. [2]This commit redoes the replacement with 4 spaces.[1]: https://www.gnu.org/software/make/manual/make.html#Conditional-Syntax[2]: https://lore.kernel.org/all/CAHk-=whJKZNZWsa-VNDKafS_VfY4a5dAjG-r8BZgWk_a-xSepw@mail.gmail.com/Suggested-by: Linus Torvalds Signed-off-by: Masahiro Yamada List of files: /linux-6.15/arch/x86/Makefile

f82811e2 - rust: Refactor the build target to allow the use of builtin targets

Fri, 20 Oct 2023 15:50:55 +0000

rust: Refactor the build target to allow the use of builtin targetsEventually we want all architectures to be using the target as definedby rustc. However currently some architectures can't do that and areusing the target.json specification. This puts in place the foundationto allow the use of the builtin target definition or a target.jsonspecification.Signed-off-by: Jamie Cunliffe Acked-by: Masahiro Yamada Tested-by: Alice Ryhl Link: https://lore.kernel.org/r/20231020155056.3495121-2-Jamie.Cunliffe@arm.com[catalin.marinas@arm.com: squashed loongarch ifneq fix from WANG Rui]Signed-off-by: Catalin Marinas List of files: /linux-6.15/arch/x86/Makefile

289d0a47 - x86/vdso: Use CONFIG_COMPAT_32 to specify vdso32

Tue, 21 Nov 2023 23:57:01 +0000

x86/vdso: Use CONFIG_COMPAT_32 to specify vdso32In arch/x86/Kconfig, COMPAT_32 is defined as (IA32_EMULATION || X86_32).Use it to eliminate redundancy in Makefile.Signed-off-by: Masahiro Yamada Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20231121235701.239606-5-masahiroy@kernel.org List of files: /linux-6.15/arch/x86/Makefile

82175d1f - kbuild: Replace tabs with spaces when followed by conditionals

Sun, 28 Jan 2024 15:10:39 +0000

kbuild: Replace tabs with spaces when followed by conditionalsThis is needed for the future (post make-4.4.1) versions of gnu make.Starting from https://git.savannah.gnu.org/cgit/make.git/commit/?id=07fcee35f058a876447c8a021f9eb1943f902534gnu make won't allow conditionals to follow recipe prefix.For example there is a tab followed by ifeq on line 324 in the root Makefile.With the new make this conditional causes the following$ make cpu.o/home/dgoncharov/src/linux-kbuild/Makefile:2063: *** missing 'endif'. Stop.make: *** [Makefile:240: __sub-make] Error 2This patch replaces tabs followed by conditionals with 8 spaces.See https://savannah.gnu.org/bugs/?64185 andhttps://savannah.gnu.org/bugs/?64259 for details.Signed-off-by: Dmitry Goncharov Reported-by: Martin Dorey Reviewed-by: Miguel Ojeda Signed-off-by: Masahiro Yamada List of files: /linux-6.15/arch/x86/Makefile