Changes in Kconfig

df7fcbef - vdso: Add generic time data storage

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

vdso: Add generic time data storageHistorically each architecture defined their own way to store the vDSOdata page. Add a generic mechanism to provide storage for that page.Furthermore this generic storage will be extended to also provideuniform storage for *non*-time-related data, like the random state orarchitecture-specific data. These will have their own pages and datastructures, so rename 'vdso_data' into 'vdso_time_data' to make thatsplit clear from the name.Also introduce a new consistent naming scheme for the symbols related tothe vDSO, which makes it clear if the symbol is accessible fromuserspace or kernel space and the type of data behind the symbol.The generic fault handler contains an optimization to prefault the vvarpage 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 List of files: /linux-6.15/lib/vdso/Kconfig

4ad10a5f - random: introduce generic vDSO getrandom() implementation

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

random: introduce generic vDSO getrandom() implementationProvide a generic C vDSO getrandom() implementation, which operates onan opaque state returned by vgetrandom_alloc() and produces random bytesthe 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 ordinarygetrandom(), while the last two arguments are a pointer to the opaqueallocated state and its size. Were all five arguments passed to thegetrandom() syscall, nothing different would happen, and the functionswould have the exact same behavior.The actual vDSO RNG algorithm implemented is the same one implemented bydrivers/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_SIGINFOcopying registers to the stack), so this is left as anarchitecture-specific fill-in. Stack-less ChaCha20 is an easy algorithmto implement on a variety of architectures, so this shouldn't be tooonerous.Initially, the state is keyless, and so the first call makes agetrandom() syscall to generate that key, and then uses it forsubsequent calls. By keeping track of a generation counter, it knowswhen its key is invalidated and it should fetch a new one using thesyscall. Later, more than just a generation counter might be used.Since MADV_WIPEONFORK is set on the opaque state, the key and relatedstate is wiped during a fork(), so secrets don't roll over into newprocesses, and the same state doesn't accidentally generate the samerandom stream. The generation counter, as well, is always >0, so thatthe 0 counter is a useful indication of a fork() or otherwiseuninitialized state.If the kernel RNG is not yet initialized, then the vDSO always calls thesyscall, because that behavior cannot be emulated in userspace, butfortunately that state is short lived and only during early boot. If ithas been initialized, then there is no need to inspect the `flags`argument, because the behavior does not change post-initializationregardless of the `flags` value.Since the opaque state passed to it is mutated, vDSO getrandom() is notreentrant, when used with the same opaque state, which libc should bemindful of.The function works over an opaque per-thread state of a particular size,which must be marked VM_WIPEONFORK, VM_DONTDUMP, VM_NORESERVE, andVM_DROPPABLE for proper operation. Over time, the nuances of theseallocations may change or grow or even differ based on architecturalfeatures.The opaque state passed to vDSO getrandom() must be allocated using themmap_flags and mmap_prot parameters provided by the vgetrandom_opaque_paramsstruct, which also contains the size of each state. That struct can beobtained 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 pereach thread, while ensuring that no single state straddles a pageboundary. Libc is expected to allocate a chunk of these on first use,and then dole them out to threads as they're created, allocating morewhen needed.vDSO getrandom() provides the ability for userspace to generate randombytes quickly and safely, and is intended to be integrated into libc'sthread management. As an illustrative example, the introduced code inthe vdso_test_getrandom self test later in this series might be used todo the same outside of libc. In a libc the various pthread-isms areexpected to be elided into libc internals.Reviewed-by: Thomas Gleixner Signed-off-by: Jason A. Donenfeld List of files: /linux-6.15/lib/vdso/Kconfig

0c68458b - vdso: Add CONFIG_GENERIC_VDSO_OVERFLOW_PROTECT

Mon, 25 Mar 2024 06:40:07 +0000

vdso: Add CONFIG_GENERIC_VDSO_OVERFLOW_PROTECTAdd CONFIG_GENERIC_VDSO_OVERFLOW_PROTECT in preparation to addmultiplication 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 List of files: /linux-6.15/lib/vdso/Kconfig

f86fd32d - lib/vdso: Cleanup clock mode storage leftovers

Fri, 07 Feb 2020 12:38:59 +0000

lib/vdso: Cleanup clock mode storage leftoversNow that all architectures are converted to use the generic storage thehelpers and conditionals can be removed.Signed-off-by: Thomas Gleixner Tested-by: Vincenzo Frascino Reviewed-by: Vincenzo Frascino Link: https://lkml.kernel.org/r/20200207124403.470699892@linutronix.de List of files: /linux-6.15/lib/vdso/Kconfig

5d51bee7 - clocksource: Add common vdso clock mode storage

Fri, 07 Feb 2020 12:38:55 +0000

clocksource: Add common vdso clock mode storageAll architectures which use the generic VDSO code have their own storagefor the VDSO clock mode. That's pointless and just requires duplicate code.Provide generic storage for it. The new Kconfig symbol is intermediate andwill be removed once all architectures are converted over.Signed-off-by: Thomas Gleixner Tested-by: Vincenzo Frascino Reviewed-by: Vincenzo Frascino Link: https://lkml.kernel.org/r/20200207124403.028046322@linutronix.de List of files: /linux-6.15/lib/vdso/Kconfig

660fd04f - lib/vdso: Prepare for time namespace support

Tue, 12 Nov 2019 01:27:09 +0000

lib/vdso: Prepare for time namespace supportTo support time namespaces in the vdso with a minimal impact on regular nontime namespace affected tasks, the namespace handling needs to be hidden ina slow path.The most obvious place is vdso_seq_begin(). If a task belongs to a timenamespace then the VVAR page which contains the system wide vdso data isreplaced with a namespace specific page which has the same layout as theVVAR page. That page has vdso_data->seq set to 1 to enforce the slow pathand vdso_data->clock_mode set to VCLOCK_TIMENS to enforce the timenamespace handling path.The extra check in the case that vdso_data->seq is odd, e.g. a concurrentupdate of the vdso data is in progress, is not really affecting regulartasks which are not part of a time namespace as the task is spin waitingfor the update to finish and vdso_data->seq to become even again.If a time namespace task hits that code path, it invokes the correspondingtime getter function which retrieves the real VVAR page, reads host timeand then adds the offset for the requested clock which is stored in thespecial VVAR page.If VDSO time namespace support is disabled the whole magic is compiled out.Initial testing shows that the disabled case is almost identical to thehost case which does not take the slow timens path. With the special timenspage installed the performance hit is constant time and in the range of5-7%.For the vdso functions which are not using the sequence count anunconditional check for vdso_data->clock_mode is added which switches tothe real vdso when the clock_mode is VCLOCK_TIMENS.[avagin: Make do_hres_timens() work with raw clocks too: choose vdso_data pointer by CS_RAW offset.]Suggested-by: Andy Lutomirski Signed-off-by: Thomas Gleixner Signed-off-by: Andrei Vagin Signed-off-by: Dmitry Safonov Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20191112012724.250792-21-dima@arista.com List of files: /linux-6.15/lib/vdso/Kconfig

50a2610a - lib: vdso: Remove CROSS_COMPILE_COMPAT_VDSO

Thu, 03 Oct 2019 17:48:38 +0000

lib: vdso: Remove CROSS_COMPILE_COMPAT_VDSOarm64 was the last architecture using CROSS_COMPILE_COMPAT_VDSO configoption. With this patch series the dependency in the architecture hasbeen removed.Remove CROSS_COMPILE_COMPAT_VDSO from the Unified vDSO library code.Cc: Thomas Gleixner Cc: Andy Lutomirski Signed-off-by: Vincenzo Frascino Signed-off-by: Will Deacon List of files: /linux-6.15/lib/vdso/Kconfig

00b26474 - lib/vdso: Provide generic VDSO implementation

Fri, 21 Jun 2019 09:52:29 +0000

lib/vdso: Provide generic VDSO implementationIn the last few years the kernel gained quite some architecture specificvdso implementations which contain very similar code.Introduce a generic VDSO implementation of gettimeofday() which will beshareable between architectures once they are converted over.The implementation is based on the current x86 VDSO code.[ tglx: Massaged changelog and made the kernel doc tabular ]Signed-off-by: Vincenzo Frascino Signed-off-by: Thomas Gleixner Tested-by: Shijith Thotton Tested-by: Andre Przywara Cc: linux-arch@vger.kernel.orgCc: linux-arm-kernel@lists.infradead.orgCc: linux-mips@vger.kernel.orgCc: linux-kselftest@vger.kernel.orgCc: Catalin Marinas Cc: Will Deacon Cc: Arnd Bergmann Cc: Russell King Cc: Ralf Baechle Cc: Paul Burton Cc: Daniel Lezcano Cc: Mark Salyzyn Cc: Peter Collingbourne Cc: Shuah Khan Cc: Dmitry Safonov <0x7f454c46@gmail.com>Cc: Rasmus Villemoes Cc: Huw Davies Link: https://lkml.kernel.org/r/20190621095252.32307-3-vincenzo.frascino@arm.com List of files: /linux-6.15/lib/vdso/Kconfig