kernel/git/stable/linux.git/security/Kconfig.hardening, branch master

hardening: Default randstruct off with rust for better allmodconfig support

2026-09-01T23:01:35+00:00

Currently randstruct does not support rust so we have Kconfig dependencies which prevent rust being enabled when randstruct is. Unfortunately this prevents rust being enabled in allmodconfig, our standard coverage build. randstruct gets turned on by default, then the dependency on !RANDSTRUCT causes rust to get disabled. Work around this by disabling randstruct by default if we have a usable rust toolchain and rust support for the architecture, circular dependencies prevent us directly depending on !RUST. This means we might end up with a configuration that disables both rust and randstruct but hopefully it's more likely go give the expected result. Signed-off-by: Mark Brown Acked-by: Miguel Ojeda Link: https://patch.msgid.link/20260901-rust-reverse-randstruct-dep-v4-1-3bfa19efe1fa@kernel.org Signed-off-by: Kees Cook

security/Kconfig.hardening: Remove tautological condition from CC_HAS_RANDSTRUCT

2026-05-27T22:20:04+00:00

Now that the minimum supported version of LLVM for building the kernel has been raised to 17.0.1, the '!Clang || Clang >= 16' dependency for CONFIG_CC_HAS_RANDSTRUCT is always true, so it can be removed. Reviewed-by: Nicolas Schier Link: https://patch.msgid.link/20260517-bump-minimum-supported-llvm-version-to-17-v2-4-b3b8cda46bdd@kernel.org Signed-off-by: Nathan Chancellor

security/Kconfig.hardening: Remove tautological condition from FORTIFY_SOURCE

2026-05-27T22:20:04+00:00

Now that the minimum supported version of LLVM for building the kernel has been raised to 17.0.1, the '!X86_32 || !Clang || Clang > 16' dependency of CONFIG_FORTIFY_SOURCE is always true, so it can be removed. Reviewed-by: Nicolas Schier Link: https://patch.msgid.link/20260517-bump-minimum-supported-llvm-version-to-17-v2-3-b3b8cda46bdd@kernel.org Signed-off-by: Nathan Chancellor

security/Kconfig.hardening: Remove tautological condition from CC_HAS_ZERO_CALL_USED_REGS

2026-05-27T22:20:04+00:00

Now that the minimum supported version of LLVM for building the kernel has been raised to 17.0.1, the '!Clang || Clang > 15.0.6' dependency for CONFIG_CC_HAS_ZERO_CALL_USED_REGS is always true, so it can be removed. Reviewed-by: Nicolas Schier Acked-by: Arnd Bergmann Link: https://patch.msgid.link/20260517-bump-minimum-supported-llvm-version-to-17-v2-2-b3b8cda46bdd@kernel.org Signed-off-by: Nathan Chancellor

rust: add bitmap API.

2025-09-22T19:52:44+00:00

Provides an abstraction for C bitmap API and bitops operations. This commit enables a Rust implementation of an Android Binder data structure from commit 15d9da3f818c ("binder: use bitmap for faster descriptor lookup"), which can be found in drivers/android/dbitmap.h. It is a step towards upstreaming the Rust port of Android Binder driver. We follow the C Bitmap API closely in naming and semantics, with a few differences that take advantage of Rust language facilities and idioms. The main types are `BitmapVec` for owned bitmaps and `Bitmap` for references to C bitmaps. * We leverage Rust type system guarantees as follows: * all (non-atomic) mutating operations require a &mut reference which amounts to exclusive access. * the `BitmapVec` type implements Send. This enables transferring ownership between threads and is needed for Binder. * the `BitmapVec` type implements Sync, which enables passing shared references &Bitmap between threads. Atomic operations can be used to safely modify from multiple threads (interior mutability), though without ordering guarantees. * The Rust API uses `{set,clear}_bit` vs `{set,clear}_bit_atomic` as names for clarity, which differs from the C naming convention `set_bit` for atomic vs `__set_bit` for non-atomic. * we include enough operations for the API to be useful. Not all operations are exposed yet in order to avoid dead code. The missing ones can be added later. * We take a fine-grained approach to safety: * Low-level bit-ops get a safe API with bounds checks. Calling with an out-of-bounds arguments to {set,clear}_bit becomes a no-op and get logged as errors. * We also introduce a RUST_BITMAP_HARDENED config, which causes invocations with out-of-bounds arguments to panic. * methods correspond to find_* C methods tolerate out-of-bounds since the C implementation does. Also here, out-of-bounds arguments are logged as errors, or panic in RUST_BITMAP_HARDENED mode. * We add a way to "borrow" bitmaps from C in Rust, to make C bitmaps that were allocated in C directly usable in Rust code (`Bitmap`). * the Rust API is optimized to represent the bitmap inline if it would fit into a pointer. This saves allocations which is relevant in the Binder use case. The underlying C bitmap is *not* exposed for raw access in Rust. Doing so would permit bypassing the Rust API and lose static guarantees. An alternative route of vendoring an existing Rust bitmap package was considered but suboptimal overall. Reusing the C implementation is preferable for a basic data structure like bitmaps. It enables Rust code to be a lot more similar and predictable with respect to C code that uses the same data structures and enables the use of code that has been tried-and-tested in the kernel, with the same performance characteristics whenever possible. We use the `usize` type for sizes and indices into the bitmap, because Rust generally always uses that type for indices and lengths and it will be more convenient if the API accepts that type. This means that we need to perform some casts to/from u32 and usize, since the C headers use unsigned int instead of size_t/unsigned long for these numbers in some places. Adds new MAINTAINERS section BITMAP API [RUST]. Suggested-by: Alice Ryhl Suggested-by: Yury Norov Signed-off-by: Burak Emir Reviewed-by: Alice Ryhl Signed-off-by: Yury Norov (NVIDIA)

kstack_erase: Support Clang stack depth tracking

2025-07-26T21:28:35+00:00

Wire up CONFIG_KSTACK_ERASE to Clang 21's new stack depth tracking callback[1] option. Link: https://clang.llvm.org/docs/SanitizerCoverage.html#tracing-stack-depth [1] Acked-by: Nicolas Schier Link: https://lore.kernel.org/r/20250724055029.3623499-4-kees@kernel.org Signed-off-by: Kees Cook

stackleak: Rename stackleak_track_stack to __sanitizer_cov_stack_depth

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

The Clang stack depth tracking implementation has a fixed name for the stack depth tracking callback, "__sanitizer_cov_stack_depth", so rename the GCC plugin function to match since the plugin has no external dependencies on naming. Link: https://lore.kernel.org/r/20250717232519.2984886-2-kees@kernel.org Signed-off-by: Kees Cook

stackleak: Rename STACKLEAK to KSTACK_ERASE

2025-07-22T04:35:01+00:00

In preparation for adding Clang sanitizer coverage stack depth tracking that can support stack depth callbacks: - Add the new top-level CONFIG_KSTACK_ERASE option which will be implemented either with the stackleak GCC plugin, or with the Clang stack depth callback support. - Rename CONFIG_GCC_PLUGIN_STACKLEAK as needed to CONFIG_KSTACK_ERASE, but keep it for anything specific to the GCC plugin itself. - Rename all exposed "STACKLEAK" names and files to "KSTACK_ERASE" (named for what it does rather than what it protects against), but leave as many of the internals alone as possible to avoid even more churn. While here, also split "prev_lowest_stack" into CONFIG_KSTACK_ERASE_METRICS, since that's the only place it is referenced from. Suggested-by: Ingo Molnar Link: https://lore.kernel.org/r/20250717232519.2984886-1-kees@kernel.org Signed-off-by: Kees Cook

Merge tag 'gcc-minimum-version-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic

2025-05-31T15:16:52+00:00

Pull compiler version requirement update from Arnd Bergmann: "Require gcc-8 and binutils-2.30 x86 already uses gcc-8 as the minimum version, this changes all other architectures to the same version. gcc-8 is used is Debian 10 and Red Hat Enterprise Linux 8, both of which are still supported, and binutils 2.30 is the oldest corresponding version on those. Ubuntu Pro 18.04 and SUSE Linux Enterprise Server 15 both use gcc-7 as the system compiler but additionally include toolchains that remain supported. With the new minimum toolchain versions, a number of workarounds for older versions can be dropped, in particular on x86_64 and arm64. Importantly, the updated compiler version allows removing two of the five remaining gcc plugins, as support for sancov and structeak features is already included in modern compiler versions. I tried collecting the known changes that are possible based on the new toolchain version, but expect that more cleanups will be possible. Since this touches multiple architectures, I merged the patches through the asm-generic tree." * tag 'gcc-minimum-version-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic: Makefile.kcov: apply needed compiler option unconditionally in CFLAGS_KCOV Documentation: update binutils-2.30 version reference gcc-plugins: remove SANCOV gcc plugin Kbuild: remove structleak gcc plugin arm64: drop binutils version checks raid6: skip avx512 checks kbuild: require gcc-8 and binutils-2.30

Revert "hardening: Disable GCC randstruct for COMPILE_TEST"

2025-05-08T16:42:40+00:00

This reverts commit f5c68a4e84f9feca3be578199ec648b676db2030. It is again possible to build "allmodconfig" with the randstruct GCC plugin, so enable it for COMPILE_TEST to catch future bugs. Signed-off-by: Kees Cook