linux.git/lib/vdso/Kconfig, branch master

vdso: Rename HAVE_GENERIC_VDSO to VDSO_DATASTORE

2026-07-15T08:49:03+00:00

Over time the meaning of HAVE_GENERIC_VDSO has become off.
Today it only controls the availability of the vDSO datastore.

Rename the symbol to match its function.

Signed-off-by: Thomas Weißschuh 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Vincenzo Frascino 
Reviewed-by: Philippe Mathieu-Daudé 
Link: https://patch.msgid.link/20260709-vdso-have_generic_vdso-v1-6-d2e1061f268b@linutronix.de

vdso: Automatically select HAVE_GENERIC_VDSO if necessary

2026-07-15T08:49:02+00:00

gettimeofday() and getrandom() in the vDSO require the vDSO datastore.

Enable it automatically if either one of them is enabled so the
architecture code doesn't need to know this.

Signed-off-by: Thomas Weißschuh 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Vincenzo Frascino 
Reviewed-by: Philippe Mathieu-Daudé 
Link: https://patch.msgid.link/20260709-vdso-have_generic_vdso-v1-4-d2e1061f268b@linutronix.de

vdso: Gate VDSO_GETRANDOM behind HAVE_GENERIC_VDSO

2025-09-04T09:23:51+00:00

All architectures which want to implement getrandom() in the vDSO need to
use the generic vDSO library.

Signed-off-by: Thomas Weißschuh 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/all/20250826-vdso-cleanups-v1-11-d9b65750e49f@linutronix.de

vdso: Drop Kconfig GENERIC_VDSO_TIME_NS

2025-09-04T09:23:50+00:00

All architectures implementing time-related functionality in the vDSO are
using the generic vDSO library which handles time namespaces properly.

Remove the now unnecessary Kconfig symbol.

Enables the use of time namespaces on architectures, which use the
generic vDSO but did not enable GENERIC_VDSO_TIME_NS, namely MIPS and arm.

Signed-off-by: Thomas Weißschuh 
Signed-off-by: Thomas Gleixner 
Acked-by: Catalin Marinas 
Link: https://lore.kernel.org/all/20250826-vdso-cleanups-v1-10-d9b65750e49f@linutronix.de

vdso: Drop Kconfig GENERIC_VDSO_DATA_STORE

2025-09-04T09:23:50+00:00

All users of the generic vDSO library also use the generic vDSO datastore.

Remove the now unnecessary Kconfig symbol.

Signed-off-by: Thomas Weißschuh 
Signed-off-by: Thomas Gleixner 
Acked-by: Catalin Marinas 
Link: https://lore.kernel.org/all/20250826-vdso-cleanups-v1-9-d9b65750e49f@linutronix.de

vdso: Drop kconfig GENERIC_COMPAT_VDSO

2025-09-04T09:23:50+00:00

This configuration is never used.

Remove it.

Signed-off-by: Thomas Weißschuh 
Signed-off-by: Thomas Gleixner 
Acked-by: Catalin Marinas 
Link: https://lore.kernel.org/all/20250826-vdso-cleanups-v1-8-d9b65750e49f@linutronix.de

vdso: Drop kconfig GENERIC_VDSO_32

2025-09-04T09:23:50+00:00

This configuration is never used.

Remove it.

Signed-off-by: Thomas Weißschuh 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/all/20250826-vdso-cleanups-v1-7-d9b65750e49f@linutronix.de

vdso: Add generic time data storage

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

Historically each architecture defined their own way to store the vDSO
data page. Add a generic mechanism to provide storage for that page.

Furthermore this generic storage will be extended to also provide
uniform storage for *non*-time-related data, like the random state or
architecture-specific data. These will have their own pages and data
structures, so rename 'vdso_data' into 'vdso_time_data' to make that
split clear from the name.

Also introduce a new consistent naming scheme for the symbols related to
the vDSO, which makes it clear if the symbol is accessible from
userspace or kernel space and the type of data behind the symbol.

The generic fault handler contains an optimization to prefault the vvar
page when the timens page is accessed. This was lifted from s390 and x86.

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-5-13a4669dfc8c@linutronix.de

random: introduce generic vDSO getrandom() implementation

2024-07-19T18:22:12+00:00

Provide a generic C vDSO getrandom() implementation, which operates on
an opaque state returned by vgetrandom_alloc() and produces random bytes
the same way as getrandom(). This has the following API signature:

  ssize_t vgetrandom(void *buffer, size_t len, unsigned int flags,
                     void *opaque_state, size_t opaque_len);

The return value and the first three arguments are the same as ordinary
getrandom(), while the last two arguments are a pointer to the opaque
allocated state and its size. Were all five arguments passed to the
getrandom() syscall, nothing different would happen, and the functions
would have the exact same behavior.

The actual vDSO RNG algorithm implemented is the same one implemented by
drivers/char/random.c, using the same fast-erasure techniques as that.
Should the in-kernel implementation change, so too will the vDSO one.

It requires an implementation of ChaCha20 that does not use any stack,
in order to maintain forward secrecy if a multi-threaded program forks
(though this does not account for a similar issue with SA_SIGINFO
copying registers to the stack), so this is left as an
architecture-specific fill-in. Stack-less ChaCha20 is an easy algorithm
to implement on a variety of architectures, so this shouldn't be too
onerous.

Initially, the state is keyless, and so the first call makes a
getrandom() syscall to generate that key, and then uses it for
subsequent calls. By keeping track of a generation counter, it knows
when its key is invalidated and it should fetch a new one using the
syscall. Later, more than just a generation counter might be used.

Since MADV_WIPEONFORK is set on the opaque state, the key and related
state is wiped during a fork(), so secrets don't roll over into new
processes, and the same state doesn't accidentally generate the same
random stream. The generation counter, as well, is always >0, so that
the 0 counter is a useful indication of a fork() or otherwise
uninitialized state.

If the kernel RNG is not yet initialized, then the vDSO always calls the
syscall, because that behavior cannot be emulated in userspace, but
fortunately that state is short lived and only during early boot. If it
has been initialized, then there is no need to inspect the `flags`
argument, because the behavior does not change post-initialization
regardless of the `flags` value.

Since the opaque state passed to it is mutated, vDSO getrandom() is not
reentrant, when used with the same opaque state, which libc should be
mindful of.

The function works over an opaque per-thread state of a particular size,
which must be marked VM_WIPEONFORK, VM_DONTDUMP, VM_NORESERVE, and
VM_DROPPABLE for proper operation. Over time, the nuances of these
allocations may change or grow or even differ based on architectural
features.

The opaque state passed to vDSO getrandom() must be allocated using the
mmap_flags and mmap_prot parameters provided by the vgetrandom_opaque_params
struct, which also contains the size of each state. That struct can be
obtained with a call to vgetrandom(NULL, 0, 0, ¶ms, ~0UL). Then,
libc can call mmap(2) and slice up the returned array into a state per
each thread, while ensuring that no single state straddles a page
boundary. Libc is expected to allocate a chunk of these on first use,
and then dole them out to threads as they're created, allocating more
when needed.

vDSO getrandom() provides the ability for userspace to generate random
bytes quickly and safely, and is intended to be integrated into libc's
thread management. As an illustrative example, the introduced code in
the vdso_test_getrandom self test later in this series might be used to
do the same outside of libc. In a libc the various pthread-isms are
expected to be elided into libc internals.

Reviewed-by: Thomas Gleixner 
Signed-off-by: Jason A. Donenfeld

vdso: Add CONFIG_GENERIC_VDSO_OVERFLOW_PROTECT

2024-04-08T13:03:06+00:00

Add CONFIG_GENERIC_VDSO_OVERFLOW_PROTECT in preparation to add
multiplication overflow protection to the VDSO time getter functions.

Suggested-by: Thomas Gleixner 
Signed-off-by: Adrian Hunter 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/20240325064023.2997-4-adrian.hunter@intel.com