Changes in Makefile

c080f2b8 - x86/vdso: Always reject undefined references during linking

Thu, 06 Mar 2025 14:07:20 +0000

x86/vdso: Always reject undefined references during linkingInstead of using a custom script to detect and fail on undefinedreferences, use --no-undefined for all VDSO linker invocations.Drop the now unused checkundef.sh script.Signed-off-by: Thomas Weißschuh Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20250306-vdso-checkundef-v2-1-a26cc315fd73@linutronix.de List of files: /linux-6.15/arch/x86/entry/vdso/Makefile

127b0e05 - vdso: Rename included Makefile

Tue, 04 Feb 2025 12:05:36 +0000

vdso: Rename included MakefileAs the Makefile is included into other Makefiles it can not be used todefine objects to be built from the current source directory.However the generic datastore will introduce such a local source file.Rename the included Makefile so it is clear how it is to be used and tomake room for a regular Makefile in lib/vdso/.Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/20250204-vdso-store-rng-v3-4-13a4669dfc8c@linutronix.de List of files: /linux-6.15/arch/x86/entry/vdso/Makefile

582077c9 - x86/cfi: Clean up linkage

Fri, 07 Feb 2025 12:15:33 +0000

x86/cfi: Clean up linkageWith the introduction of kCFI the addition of ENDBR toSYM_FUNC_START* no longer suffices to make the function indirectlycallable. This now requires the use of SYM_TYPED_FUNC_START.As such, remove the implicit ENDBR from SYM_FUNC_START* and add someexplicit annotations to fix things up again.Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Sami Tolvanen Link: https://lore.kernel.org/r/20250207122546.409116003@infradead.org List of files: /linux-6.15/arch/x86/entry/vdso/Makefile

33385150 - x86: vdso: Wire up getrandom() vDSO implementation

Fri, 18 Nov 2022 16:38:23 +0000

x86: vdso: Wire up getrandom() vDSO implementationHook up the generic vDSO implementation to the x86 vDSO data page. Sincethe existing vDSO infrastructure is heavily based on the timekeepingfunctionality, which works over arrays of bases, a new macro isintroduced for vvars that are not arrays.The vDSO function requires a ChaCha20 implementation that does not writeto the stack, yet can still do an entire ChaCha20 permutation, soprovide this using SSE2, since this is userland code that must work onall x86-64 processors.Reviewed-by: Thomas Gleixner Reviewed-by: Samuel Neves # for vgetrandom-chacha.SSigned-off-by: Jason A. Donenfeld List of files: /linux-6.15/arch/x86/entry/vdso/Makefile

7f7f6f7a - Makefile: remove redundant tool coverage variables

Mon, 06 May 2024 13:35:43 +0000

Makefile: remove redundant tool coverage variablesNow Kbuild provides reasonable defaults for objtool, sanitizers, andprofilers.Remove redundant variables.Note:This commit changes the coverage for some objects: - include arch/mips/vdso/vdso-image.o into UBSAN, GCOV, KCOV - include arch/sparc/vdso/vdso-image-*.o into UBSAN - include arch/sparc/vdso/vma.o into UBSAN - include arch/x86/entry/vdso/extable.o into KASAN, KCSAN, UBSAN, GCOV, KCOV - include arch/x86/entry/vdso/vdso-image-*.o into KASAN, KCSAN, UBSAN, GCOV, KCOV - include arch/x86/entry/vdso/vdso32-setup.o into KASAN, KCSAN, UBSAN, GCOV, KCOV - include arch/x86/entry/vdso/vma.o into GCOV, KCOV - include arch/x86/um/vdso/vma.o into KASAN, GCOV, KCOVI believe these are positive effects because all of them are kernelspace objects.Signed-off-by: Masahiro Yamada Reviewed-by: Kees Cook Tested-by: Roberto Sassu List of files: /linux-6.15/arch/x86/entry/vdso/Makefile

b1992c37 - kbuild: use $(src) instead of $(srctree)/$(src) for source directory

Sat, 27 Apr 2024 14:55:02 +0000

kbuild: use $(src) instead of $(srctree)/$(src) for source directoryKbuild conventionally uses $(obj)/ for generated files, and $(src)/ forchecked-in source files. It is merely a convention without any functionaldifference. In fact, $(obj) and $(src) are exactly the same, as definedin scripts/Makefile.build: src := $(obj)When the kernel is built in a separate output directory, $(src) doesnot accurately reflect the source directory location. While Kbuildresolves this discrepancy by specifying VPATH=$(srctree) to search forsource files, it does not cover all cases. For example, when adding aheader search path for local headers, -I$(srctree)/$(src) is typicallypassed to the compiler.This introduces inconsistency between upstream and downstream Makefilesbecause $(src) is used instead of $(srctree)/$(src) for the latter.To address this inconsistency, this commit changes the semantics of$(src) so that it always points to the directory in the source tree.Going forward, the variables used in Makefiles will have the followingmeanings: $(obj) - directory in the object tree $(src) - directory in the source tree (changed by this commit) $(objtree) - the top of the kernel object tree $(srctree) - the top of the kernel source treeConsequently, $(srctree)/$(src) in upstream Makefiles need to be replacedwith $(src).Signed-off-by: Masahiro Yamada Reviewed-by: Nicolas Schier List of files: /linux-6.15/arch/x86/entry/vdso/Makefile

4969d75d - x86/vdso: Fix rethunk patching for vdso-image-x32.o too

Tue, 26 Mar 2024 09:47:14 +0000

x86/vdso: Fix rethunk patching for vdso-image-x32.o tooIn a similar fashion to b388e57d4628 ("x86/vdso: Fix rethunk patching for vdso-image-{32,64}.o")annotate vdso-image-x32.o too for objtool so that it gets annotatedproperly and the unused return thunk warning doesn't fire.Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202403251454.23df6278-lkp@intel.comSigned-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/202403251454.23df6278-lkp@intel.com List of files: /linux-6.15/arch/x86/entry/vdso/Makefile

bf48d9b7 - kbuild: change tool coverage variables to take the path relative to $(obj)

Sat, 17 Feb 2024 05:55:03 +0000

kbuild: change tool coverage variables to take the path relative to $(obj)Commit 54b8ae66ae1a ("kbuild: change *FLAGS_.o to take thepath relative to $(obj)") changed the syntax of per-file compiler flags.The situation is the same for the following variables: OBJECT_FILES_NON_STANDARD_.o GCOV_PROFILE_.o KASAN_SANITIZE_.o KMSAN_SANITIZE_.o KMSAN_ENABLE_CHECKS_.o UBSAN_SANITIZE_.o KCOV_INSTRUMENT_.o KCSAN_SANITIZE_.o KCSAN_INSTRUMENT_BARRIERS_.oThe is the filename of the target with its directory andsuffix stripped.This syntax comes into a trouble when two files with the same basenameappear in one Makefile, for example: obj-y += dir1/foo.o obj-y += dir2/foo.o OBJECT_FILES_NON_STANDARD_foo.o := yOBJECT_FILES_NON_STANDARD_foo.o is applied to both dir1/foo.o anddir2/foo.o. This syntax is not flexbile enough to handle cases whereone of them is a standard object, but the other is not.It is more sensible to use the relative path to the Makefile, like this: obj-y += dir1/foo.o OBJECT_FILES_NON_STANDARD_dir1/foo.o := y obj-y += dir2/foo.o OBJECT_FILES_NON_STANDARD_dir2/foo.o := yTo maintain the current behavior, I made adjustments to the following twoMakefiles: - arch/x86/entry/vdso/Makefile, which compiles vclock_gettime.o, vgetcpu.o, and their vdso32 variants. - arch/x86/kvm/Makefile, which compiles vmx/vmenter.o and svm/vmenter.oSigned-off-by: Masahiro Yamada Reviewed-by: Nicolas Schier Acked-by: Sean Christopherson List of files: /linux-6.15/arch/x86/entry/vdso/Makefile

b7bcffe7 - x86/vdso/kbuild: Group non-standard build attributes and primary object file rules together

Thu, 22 Feb 2024 09:20:58 +0000

x86/vdso/kbuild: Group non-standard build attributes and primary object file rules togetherThe fresh changes to the vDSO Makefile in: 289d0a475c3e ("x86/vdso: Use CONFIG_COMPAT_32 to specify vdso32") 329b77b59f83 ("x86/vdso: Simplify obj-y addition")Conflicted with a pending change in: b388e57d4628e ("x86/vdso: Fix rethunk patching for vdso-image-{32,64}.o")Which was resolved in a simple fasion in this merge commit: f14df823a61e ("Merge branch 'x86/vdso' into x86/core, to resolve conflict and to prepare for dependent changes")... but all these changes make me look and notice a bit of historic baggageleft in the Makefile: - Disordered build rules where non-standard build attributes relating to were placed sometimes several lines after - and sometimes *before* the .o build rules of the object files... Functional but inconsistent. - Inconsistent vertical spacing, stray whitespaces, inconsistent spelling of 'vDSO' over the years, a few spelling mistakes and inconsistent capitalization of comment blocks.Tidy it all up. No functional changes intended.Cc: Masahiro Yamada Cc: Borislav Petkov (AMD) Signed-off-by: Ingo Molnar List of files: /linux-6.15/arch/x86/entry/vdso/Makefile

b388e57d - x86/vdso: Fix rethunk patching for vdso-image-{32,64}.o

Tue, 20 Feb 2024 05:57:18 +0000

x86/vdso: Fix rethunk patching for vdso-image-{32,64}.oFor CONFIG_RETHUNK kernels, objtool annotates all the function returnsites so they can be patched during boot. By design, afterapply_returns() is called, all tail-calls to the compiler-generateddefault return thunk (__x86_return_thunk) should be patched out andreplaced with whatever's needed for any mitigations (or lack thereof).The commit 4461438a8405 ("x86/retpoline: Ensure default return thunk isn't used at runtime")adds a runtime check and a WARN_ONCE() if the default return thunk evergets executed after alternatives have been applied. This warning isa sanity check to make sure objtool and apply_returns() are doing theirjob.As Nathan reported, that check found something: Unpatched return thunk in use. This should not happen! WARNING: CPU: 0 PID: 1 at arch/x86/kernel/cpu/bugs.c:2856 __warn_thunk+0x27/0x40 RIP: 0010:__warn_thunk+0x27/0x40 Call Trace: ? show_regs ? __warn ? __warn_thunk ? report_bug ? console_unlock ? handle_bug ? exc_invalid_op ? asm_exc_invalid_op ? ia32_binfmt_init ? __warn_thunk warn_thunk_thunk do_one_initcall kernel_init_freeable ? __pfx_kernel_init kernel_init ret_from_fork ? __pfx_kernel_init ret_from_fork_asm Boris debugged to find that the unpatched return site was ininit_vdso_image_64(), and its translation unit wasn't being analyzed byobjtool, so it never got annotated. So it got ignored byapply_returns().This is only a minor issue, as this function is only called during boot.Still, objtool needs full visibility to the kernel. Fix it by enablingobjtool on vdso-image-{32,64}.o.Note this problem can only be seen with !CONFIG_X86_KERNEL_IBT, as thatrequires objtool to run individually on all translation units rather onvmlinux.o. [ bp: Massage commit message. ]Reported-by: Nathan Chancellor Signed-off-by: Josh Poimboeuf Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20240215032049.GA3944823@dev-arch.thelio-3990X List of files: /linux-6.15/arch/x86/entry/vdso/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/entry/vdso/Makefile

ac9275b3 - x86/vdso: Use $(addprefix ) instead of $(foreach )

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

x86/vdso: Use $(addprefix ) instead of $(foreach )$(addprefix ) is slightly shorter and more intuitive.Signed-off-by: Masahiro Yamada Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20231121235701.239606-4-masahiroy@kernel.org List of files: /linux-6.15/arch/x86/entry/vdso/Makefile

329b77b5 - x86/vdso: Simplify obj-y addition

Tue, 21 Nov 2023 23:56:59 +0000

x86/vdso: Simplify obj-y additionAdd objects to obj-y in a more straightforward way.CONFIG_X86_32 and CONFIG_IA32_EMULATION are not enabled simultaneously,but even if they are, Kbuild graciously deduplicates obj-y entries.Signed-off-by: Masahiro Yamada Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20231121235701.239606-3-masahiroy@kernel.org List of files: /linux-6.15/arch/x86/entry/vdso/Makefile

31a4ebee - x86/vdso: Consolidate targets and clean-files

Tue, 21 Nov 2023 23:56:58 +0000

x86/vdso: Consolidate targets and clean-files'targets' and 'clean-files' do not need to list the same files becausethe files listed in 'targets' are cleaned up.Refactor the code.Signed-off-by: Masahiro Yamada Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20231121235701.239606-2-masahiroy@kernel.org List of files: /linux-6.15/arch/x86/entry/vdso/Makefile

aefb2f2e - x86/bugs: Rename CONFIG_RETPOLINE => CONFIG_MITIGATION_RETPOLINE

Tue, 21 Nov 2023 16:07:32 +0000

x86/bugs: Rename CONFIG_RETPOLINE => CONFIG_MITIGATION_RETPOLINEStep 5/10 of the namespace unification of CPU mitigations related Kconfig options.[ mingo: Converted a few more uses in comments/messages as well. ]Suggested-by: Josh Poimboeuf Signed-off-by: Breno Leitao Signed-off-by: Ingo Molnar Reviewed-by: Ariel Miculas Acked-by: Josh Poimboeuf Cc: Linus Torvalds Link: https://lore.kernel.org/r/20231121160740.1249350-6-leitao@debian.org List of files: /linux-6.15/arch/x86/entry/vdso/Makefile

56769ba4 - kbuild: unify vdso_install rules

Sat, 14 Oct 2023 10:54:35 +0000

kbuild: unify vdso_install rulesCurrently, there is no standard implementation for vdso_install,leading to various issues: 1. Code duplication Many architectures duplicate similar code just for copying files to the install destination. Some architectures (arm, sparc, x86) create build-id symlinks, introducing more code duplication. 2. Unintended updates of in-tree build artifacts The vdso_install rule depends on the vdso files to install. It may update in-tree build artifacts. This can be problematic, as explained in commit 19514fc665ff ("arm, kbuild: make "make install" not depend on vmlinux"). 3. Broken code in some architectures Makefile code is often copied from one architecture to another without proper adaptation. 'make vdso_install' for parisc does not work. 'make vdso_install' for s390 installs vdso64, but not vdso32.To address these problems, this commit introduces a generic vdso_installrule.Architectures that support vdso_install need to define vdso-install-yin arch/*/Makefile. vdso-install-y lists the files to install.For example, arch/x86/Makefile looks like this: vdso-install-$(CONFIG_X86_64) += arch/x86/entry/vdso/vdso64.so.dbg vdso-install-$(CONFIG_X86_X32_ABI) += arch/x86/entry/vdso/vdsox32.so.dbg vdso-install-$(CONFIG_X86_32) += arch/x86/entry/vdso/vdso32.so.dbg vdso-install-$(CONFIG_IA32_EMULATION) += arch/x86/entry/vdso/vdso32.so.dbgThese files will be installed to $(MODLIB)/vdso/ with the .dbg suffix,if exists, stripped away.vdso-install-y can optionally take the second field after the colonseparator. This is needed because some architectures install a vdsofile as a different base name.The following is a snippet from arch/arm64/Makefile. vdso-install-$(CONFIG_COMPAT_VDSO) += arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.soThis will rename vdso.so.dbg to vdso32.so during installation. If sucharchitectures change their implementation so that the base names match,this workaround will go away.Signed-off-by: Masahiro Yamada Acked-by: Sven Schnelle # s390Reviewed-by: Nicolas Schier Reviewed-by: Guo Ren Acked-by: Helge Deller # pariscAcked-by: Catalin Marinas Acked-by: Russell King (Oracle) List of files: /linux-6.15/arch/x86/entry/vdso/Makefile

b587fef1 - x86/vdso: Run objtool on vdso32-setup.o

Tue, 10 Oct 2023 17:10:19 +0000

x86/vdso: Run objtool on vdso32-setup.ovdso32-setup.c is part of the main kernel image and should not beexcluded from objtool. Objtool is necessary in part for ensuring thatreturns in this file are correctly patched to the appropriate returnthunk at runtime.Signed-off-by: David Kaplan Signed-off-by: Ingo Molnar Signed-off-by: Borislav Petkov (AMD) Acked-by: Borislav Petkov (AMD) Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20231010171020.462211-3-david.kaplan@amd.com List of files: /linux-6.15/arch/x86/entry/vdso/Makefile

aff69273 - vdso: Improve cmd_vdso_check to check all dynamic relocations

Fri, 10 Mar 2023 19:07:50 +0000

vdso: Improve cmd_vdso_check to check all dynamic relocationsThe actual intention is that no dynamic relocation exists in the VDSO. Forthis the VDSO build validates that the resulting .so file does not have anyrelocations which are specified via $(ARCH_REL_TYPE_ABS) per architecture,which is fragile as e.g. ARM64 lacks an entry for R_AARCH64_RELATIVE. Asideof that ARCH_REL_TYPE_ABS is a misnomer as it checks for relativerelocations too.However, some GNU ld ports produce unneeded R_*_NONE relocation entries. Ifa port fails to determine the exact .rel[a].dyn size, the trailing zerosbecome R_*_NONE relocations. E.g. ld's powerpc port recently fixedhttps://sourceware.org/bugzilla/show_bug.cgi?id=29540). R_*_NONE aregenerally a no-op in the dynamic loaders. So just ignore them.Remove the ARCH_REL_TYPE_ABS defines and just validate that the resulting.so file does not contain any R_* relocation entries except R_*_NONE.Signed-off-by: Fangrui Song Signed-off-by: Thomas Gleixner Tested-by: Vincenzo Frascino # for aarch64Reviewed-by: Christophe Leroy Reviewed-by: Vincenzo Frascino # for vDSO, aarch64Acked-by: Michael Ellerman (powerpc)Link: https://lore.kernel.org/r/20230310190750.3323802-1-maskray@google.com List of files: /linux-6.15/arch/x86/entry/vdso/Makefile

92d33063 - x86/vdso: Provide getcpu for x86-32.

Fri, 25 Nov 2022 09:42:15 +0000

x86/vdso: Provide getcpu for x86-32.Wire up __vdso_getcpu() for x86-32.The 64bit version is reused with trivial modifications. Contrary tovclock_gettime.c there is no requirement to fake any defines in the case of32bit VDSO on a 64bit kernel because the GDT entry from which the CPU andnode information is read is always the native one.Adopt vdso_getcpu.c by: - removing the unneeded time* header files which lead to compile errors for 32bit. - adding segment.h which provides vdso_read_cpunode() and the defines required by it.Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20221125094216.3663444-3-bigeasy@linutronix.de List of files: /linux-6.15/arch/x86/entry/vdso/Makefile

bea75b33 - x86/Kconfig: Introduce function padding

Thu, 15 Sep 2022 11:11:18 +0000

x86/Kconfig: Introduce function paddingNow that all functions are 16 byte aligned, add 16 bytes of NOPpadding in front of each function. This prepares things for softwarecall stack tracking and kCFI/FineIBT.This significantly increases kernel .text size, around 5.1% on ax86_64-defconfig-ish build.However, per the random access argument used for alignment, these 16extra bytes are code that wouldn't be used. Performance measurementsback this up by showing no significant performance regressions.Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20220915111146.950884492@infradead.org List of files: /linux-6.15/arch/x86/entry/vdso/Makefile