kernel/linux.git/arch/arm/vdso, branch v6.18.21

stackleak: Split KSTACK_ERASE_CFLAGS from GCC_PLUGINS_CFLAGS

2025-07-22T04:40:57+00:00

In preparation for Clang stack depth tracking for KSTACK_ERASE, split the stackleak-specific cflags out of GCC_PLUGINS_CFLAGS into KSTACK_ERASE_CFLAGS. Link: https://lore.kernel.org/r/20250717232519.2984886-3-kees@kernel.org Signed-off-by: Kees Cook

arm: vdso: Switch to generic storage implementation

2025-02-21T08:54:02+00:00

The generic storage implementation provides the same features as the custom one. However it can be shared between architectures, making maintenance easier. Co-developed-by: Nam Cao Signed-off-by: Nam Cao Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/20250204-vdso-store-rng-v3-11-13a4669dfc8c@linutronix.de

vdso: Rename included Makefile

2025-02-21T08:54:01+00:00

As the Makefile is included into other Makefiles it can not be used to define 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 to make 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

ARM: vdso: Remove assembly for datapage access

2024-11-02T11:37:33+00:00

vdso/datapage.h provides a hidden declaration for _vdso_data. When using it the compiler will automatically generate PC-relative accesses which avoids the need for a custom assembly-based accessor. Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-7-b64f0842d512@linutronix.de

Makefile: remove redundant tool coverage variables

2024-05-14T14:35:48+00:00

Now Kbuild provides reasonable defaults for objtool, sanitizers, and profilers. 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, KCOV I believe these are positive effects because all of them are kernel space objects. Signed-off-by: Masahiro Yamada Reviewed-by: Kees Cook Tested-by: Roberto Sassu

arch: vdso: consolidate gettime prototypes

2023-11-23T10:32:32+00:00

The VDSO functions are defined as globals in the kernel sources but intended to be called from userspace, so there is no need to declare them in a kernel side header. Without a prototype, this now causes warnings such as arch/mips/vdso/vgettimeofday.c:14:5: error: no previous prototype for '__vdso_clock_gettime' [-Werror=missing-prototypes] arch/mips/vdso/vgettimeofday.c:28:5: error: no previous prototype for '__vdso_gettimeofday' [-Werror=missing-prototypes] arch/mips/vdso/vgettimeofday.c:36:5: error: no previous prototype for '__vdso_clock_getres' [-Werror=missing-prototypes] arch/mips/vdso/vgettimeofday.c:42:5: error: no previous prototype for '__vdso_clock_gettime64' [-Werror=missing-prototypes] arch/sparc/vdso/vclock_gettime.c:254:1: error: no previous prototype for '__vdso_clock_gettime' [-Werror=missing-prototypes] arch/sparc/vdso/vclock_gettime.c:282:1: error: no previous prototype for '__vdso_clock_gettime_stick' [-Werror=missing-prototypes] arch/sparc/vdso/vclock_gettime.c:307:1: error: no previous prototype for '__vdso_gettimeofday' [-Werror=missing-prototypes] arch/sparc/vdso/vclock_gettime.c:343:1: error: no previous prototype for '__vdso_gettimeofday_stick' [-Werror=missing-prototypes] Most architectures have already added workarounds for these by adding declarations somewhere, but since these are all compatible, we should really just have one copy, with an #ifdef check for the 32-bit vs 64-bit variant and use that everywhere. Unfortunately, the sparc an um versions are currently incompatible since they never added support for __vdso_clock_gettime64() in 32-bit userland. For the moment, I'm leaving this one out, as I can't easily test it and it requires a larger rework. Reviewed-by: Vincenzo Frascino Signed-off-by: Arnd Bergmann

kbuild: unify vdso_install rules

2023-10-28T12:09:02+00:00

Currently, 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_install rule. Architectures that support vdso_install need to define vdso-install-y in 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.dbg These 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 colon separator. This is needed because some architectures install a vdso file 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.so This will rename vdso.so.dbg to vdso32.so during installation. If such architectures change their implementation so that the base names match, this workaround will go away. Signed-off-by: Masahiro Yamada Acked-by: Sven Schnelle # s390 Reviewed-by: Nicolas Schier Reviewed-by: Guo Ren Acked-by: Helge Deller # parisc Acked-by: Catalin Marinas Acked-by: Russell King (Oracle)

ARM: 9313/1: vdso: add missing prototypes

2023-06-19T08:35:58+00:00

The __vdso_clock_* functions have no prototype, and the __eabi_unwind_cpp_pr* functions have a prototype in a header that is not included before the definition: arch/arm/vdso/vgettimeofday.c:10:5: error: no previous prototype for '__vdso_clock_gettime' [-Werror=missing-prototypes] arch/arm/vdso/vgettimeofday.c:16:5: error: no previous prototype for '__vdso_clock_gettime64' [-Werror=missing-prototypes] arch/arm/vdso/vgettimeofday.c:22:5: error: no previous prototype for '__vdso_gettimeofday' [-Werror=missing-prototypes] arch/arm/vdso/vgettimeofday.c:28:5: error: no previous prototype for '__vdso_clock_getres' [-Werror=missing-prototypes] arch/arm/vdso/vgettimeofday.c:36:6: error: no previous prototype for '__aeabi_unwind_cpp_pr0' [-Werror=missing-prototypes] arch/arm/vdso/vgettimeofday.c:40:6: error: no previous prototype for '__aeabi_unwind_cpp_pr1' [-Werror=missing-prototypes] arch/arm/vdso/vgettimeofday.c:44:6: error: no previous prototype for '__aeabi_unwind_cpp_pr2' [-Werror=missing-prototypes] Add the prototypes in an appropriate header and ensure that both are included here. Reviewed-by: Kees Cook Signed-off-by: Arnd Bergmann Signed-off-by: Russell King (Oracle)

vdso: Improve cmd_vdso_check to check all dynamic relocations

2023-03-21T20:15:34+00:00

The actual intention is that no dynamic relocation exists in the VDSO. For this the VDSO build validates that the resulting .so file does not have any relocations which are specified via $(ARCH_REL_TYPE_ABS) per architecture, which is fragile as e.g. ARM64 lacks an entry for R_AARCH64_RELATIVE. Aside of that ARCH_REL_TYPE_ABS is a misnomer as it checks for relative relocations too. However, some GNU ld ports produce unneeded R_*_NONE relocation entries. If a port fails to determine the exact .rel[a].dyn size, the trailing zeros become R_*_NONE relocations. E.g. ld's powerpc port recently fixed https://sourceware.org/bugzilla/show_bug.cgi?id=29540). R_*_NONE are generally 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 aarch64 Reviewed-by: Christophe Leroy Reviewed-by: Vincenzo Frascino # for vDSO, aarch64 Acked-by: Michael Ellerman (powerpc) Link: https://lore.kernel.org/r/20230310190750.3323802-1-maskray@google.com

ARM: 9253/1: ubsan: select ARCH_HAS_UBSAN_SANITIZE_ALL

2022-11-07T14:19:00+00:00

To enable UBSAN on ARM, this patch enables ARCH_HAS_UBSAN_SANITIZE_ALL from arm confiuration. Basic kernel bootup test is passed on arm with CONFIG_UBSAN_SANITIZE_ALL enabled. [florian: rebased against v6.0-rc7] Signed-off-by: Seung-Woo Kim Signed-off-by: Florian Fainelli Signed-off-by: Russell King (Oracle)