linux.git/arch/s390/kernel/vdso64, branch master

s390/vdso: Rename vdso64 to vdso

2025-11-25T14:28:07+00:00

Since compat is gone there is only a 64 bit vdso left.
Remove the superfluous "64" suffix everywhere.

Reviewed-by: Jens Remus 
Signed-off-by: Heiko Carstens

s390/vdso: Use common STABS_DEBUG and DWARF_DEBUG macros

2025-11-25T14:28:07+00:00

This simplifies the vDSO linker script.  The ELF_DETAILS macro was not
used in addition, as done on arm64 and powerpc, as that would introduce
an empty .modinfo section.

Note that this rearranges the .comment section to follow after all of
the debug sections.

Signed-off-by: Jens Remus 
Reviewed-by: Heiko Carstens 
Signed-off-by: Heiko Carstens

s390: Add stackprotector support

2025-11-24T10:45:21+00:00

Stackprotector support was previously unavailable on s390 because by
default compilers generate code which is not suitable for the kernel:
the canary value is accessed via thread local storage, where the address
of thread local storage is within access registers 0 and 1.

Using those registers also for the kernel would come with a significant
performance impact and more complicated kernel entry/exit code, since
access registers contents would have to be exchanged on every kernel entry
and exit.

With the upcoming gcc 16 release new compiler options will become available
which allow to generate code suitable for the kernel. [1]

Compiler option -mstack-protector-guard=global instructs gcc to generate
stackprotector code that refers to a global stackprotector canary value via
symbol __stack_chk_guard. Access to this value is guaranteed to occur via
larl and lgrl instructions.

Furthermore, compiler option -mstack-protector-guard-record generates a
section containing all code addresses that reference the canary value.

To allow for per task canary values the instructions which load the address
of __stack_chk_guard are patched so they access a lowcore field instead: a
per task canary value is available within the task_struct of each task, and
is written to the per-cpu lowcore location on each context switch.

Also add sanity checks and debugging option to be consistent with other
kernel code patching mechanisms.

Full debugging output can be enabled with the following kernel command line
options:

debug_stackprotector
bootdebug
ignore_loglevel
earlyprintk
dyndbg="file stackprotector.c +p"

Example debug output:

stackprot: 0000021e402d4eda: c010005a9ae3 -> c01f00070240

where ":  -> ".

[1] gcc commit 0cd1f03939d5 ("s390: Support global stack protector")

Reviewed-by: Sven Schnelle 
Signed-off-by: Heiko Carstens

s390/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 
Acked-by: Heiko Carstens 
Link: https://lore.kernel.org/all/20250204-vdso-store-rng-v3-12-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

s390/Kconfig: Select VMAP_STACK unconditionally

2024-12-10T14:41:58+00:00

There is no point in supporting !VMAP_STACK kernel builds. VMAP_STACK has
proven to work since many years. Also, since KASAN_VMALLOC is supported,
kernels built with !VMAP_STACK are completely untested.

Therefore select VMAP_STACK unconditionally and remove all config options
and code required for !VMAP_STACK builds.

Acked-by: Christian Borntraeger 
Reviewed-by: Vasily Gorbik 
Signed-off-by: Heiko Carstens 
Signed-off-by: Alexander Gordeev

s390/vdso: Drop LBASE_VDSO

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

This constant is always "0", providing no value and making the logic
harder to understand.
Also prepare for a consolidation of the vdso linkerscript logic by
aligning it with other architectures.

Signed-off-by: Thomas Weißschuh 
Signed-off-by: Thomas Gleixner 
Acked-by: Heiko Carstens 
Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-3-b64f0842d512@linutronix.de

s390/vdso: Use one large alternative instead of an alternative branch

2024-09-23T15:57:04+00:00

Replace the alternative branch with a larger alternative that contains
both paths. That way the two paths are closer together and it is easier
to change both paths if the need should arise.

Signed-off-by: Heiko Carstens 
Reviewed-by: Jens Remus 
Signed-off-by: Vasily Gorbik

s390/vdso: Use SYM_DATA_START_LOCAL()/SYM_DATA_END() for data objects

2024-09-23T15:57:04+00:00

Use SYM_DATA_START_LOCAL()/SYM_DATA_END() in vgetrandom-chacha.S so
that the constants end up in an object with correct size:

readelf -Ws vgetrandom-chacha.o
   Num:    Value          Size Type    Bind   Vis      Ndx Name
   ...
     5: 0000000000000000    32 OBJECT  LOCAL  DEFAULT    5 chacha20_constants

Signed-off-by: Heiko Carstens 
Reviewed-by: Jens Remus 
Signed-off-by: Vasily Gorbik

s390/vdso: Use macros for annotation of asm functions

2024-09-23T15:57:04+00:00

Use the macros SYM_FUNC_START() and SYM_FUNC_END() to annotate the
functions in assembly.

Signed-off-by: Jens Remus 
Signed-off-by: Heiko Carstens 
Acked-by: Vasily Gorbik 
Signed-off-by: Vasily Gorbik