Changes in Kconfig.hardening

9331258bc129a007a5f10e2a2b45d1e71624d115 - security/Kconfig.hardening: Remove tautological condition from CC_HAS_RANDSTRUCT

Mon, 18 May 2026 01:05:07 +0200

security/Kconfig.hardening: Remove tautological condition from CC_HAS_RANDSTRUCTNow that the minimum supported version of LLVM for building the kernelhas been raised to 17.0.1, the '!Clang || Clang >= 16' dependency forCONFIG_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.orgSigned-off-by: Nathan Chancellor List of files: /linux/security/Kconfig.hardening

8ad2017578c99ba7851bca5df52f82a3ade2e603 - security/Kconfig.hardening: Remove tautological condition from FORTIFY_SOURCE

Mon, 18 May 2026 01:05:06 +0200

security/Kconfig.hardening: Remove tautological condition from FORTIFY_SOURCENow that the minimum supported version of LLVM for building the kernelhas been raised to 17.0.1, the '!X86_32 || !Clang || Clang > 16'dependency of CONFIG_FORTIFY_SOURCE is always true, so it can beremoved.Reviewed-by: Nicolas Schier Link: https://patch.msgid.link/20260517-bump-minimum-supported-llvm-version-to-17-v2-3-b3b8cda46bdd@kernel.orgSigned-off-by: Nathan Chancellor List of files: /linux/security/Kconfig.hardening

813fe686e90b433b6d13cfd157b8008825193872 - security/Kconfig.hardening: Remove tautological condition from CC_HAS_ZERO_CALL_USED_REGS

Mon, 18 May 2026 01:05:05 +0200

security/Kconfig.hardening: Remove tautological condition from CC_HAS_ZERO_CALL_USED_REGSNow that the minimum supported version of LLVM for building the kernelhas been raised to 17.0.1, the '!Clang || Clang > 15.0.6' dependency forCONFIG_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.orgSigned-off-by: Nathan Chancellor List of files: /linux/security/Kconfig.hardening

11eca92a2caebcc2b3b65ca290385ff4b0498946 - rust: add bitmap API.

Mon, 08 Sep 2025 09:21:53 +0200

rust: add bitmap API.Provides an abstraction for C bitmap API and bitops operations.This commit enables a Rust implementation of an Android Binderdata structure from commit 15d9da3f818c ("binder: use bitmap for fasterdescriptor 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, witha few differences that take advantage of Rust language facilitiesand 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 sowould permit bypassing the Rust API and lose static guarantees.An alternative route of vendoring an existing Rust bitmap package wasconsidered but suboptimal overall. Reusing the C implementation ispreferable for a basic data structure like bitmaps. It enables Rustcode to be a lot more similar and predictable with respect to C codethat uses the same data structures and enables the use of code thathas been tried-and-tested in the kernel, with the same performancecharacteristics whenever possible.We use the `usize` type for sizes and indices into the bitmap,because Rust generally always uses that type for indices and lengthsand it will be more convenient if the API accepts that type. This meansthat we need to perform some casts to/from u32 and usize, since the Cheaders use unsigned int instead of size_t/unsigned long for thesenumbers 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) List of files: /linux/security/Kconfig.hardening

a8f0b1f8ef628bd1003eed650862836e97b89fdd - kstack_erase: Support Clang stack depth tracking

Thu, 24 Jul 2025 07:50:28 +0200

kstack_erase: Support Clang stack depth trackingWire up CONFIG_KSTACK_ERASE to Clang 21's new stack depth trackingcallback[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.orgSigned-off-by: Kees Cook List of files: /linux/security/Kconfig.hardening

9ea1e8d28add49ab3c1ecfa43f08d92ee23f3e33 - stackleak: Rename stackleak_track_stack to __sanitizer_cov_stack_depth

Fri, 18 Jul 2025 01:25:07 +0200

stackleak: Rename stackleak_track_stack to __sanitizer_cov_stack_depthThe Clang stack depth tracking implementation has a fixed name forthe stack depth tracking callback, "__sanitizer_cov_stack_depth", sorename the GCC plugin function to match since the plugin has no externaldependencies on naming.Link: https://lore.kernel.org/r/20250717232519.2984886-2-kees@kernel.orgSigned-off-by: Kees Cook List of files: /linux/security/Kconfig.hardening

57fbad15c2eee77276a541c616589b32976d2b8e - stackleak: Rename STACKLEAK to KSTACK_ERASE

Fri, 18 Jul 2025 01:25:06 +0200

stackleak: Rename STACKLEAK to KSTACK_ERASEIn preparation for adding Clang sanitizer coverage stack depth trackingthat 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.orgSigned-off-by: Kees Cook List of files: /linux/security/Kconfig.hardening

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

Sat, 31 May 2025 17:16:52 +0200

Merge tag 'gcc-minimum-version-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-genericPull 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 List of files: /linux/security/Kconfig.hardening

f0cd6012c40da99b45f8f63052b97ec89d5f307b - Revert "hardening: Disable GCC randstruct for COMPILE_TEST"

Sat, 26 Apr 2025 09:37:55 +0200

Revert "hardening: Disable GCC randstruct for COMPILE_TEST"This reverts commit f5c68a4e84f9feca3be578199ec648b676db2030.It is again possible to build "allmodconfig" with the randstruct GCCplugin, so enable it for COMPILE_TEST to catch future bugs.Signed-off-by: Kees Cook List of files: /linux/security/Kconfig.hardening

8530ea3c9b9747faba46ed3a59ad103b894f1189 - Kbuild: remove structleak gcc plugin

Mon, 07 Apr 2025 21:21:14 +0200

Kbuild: remove structleak gcc plugingcc-12 and higher support the -ftrivial-auto-var-init= flag, aftergcc-8 is the minimum version, this is half of the supported ones, andthe vast majority of the versions that users are actually likely tohave, so it seems like a good time to stop having the fallbackplugin implementationOlder toolchains are still able to build kernels normally withoutthis plugin, but won't be able to use variable initialization..Signed-off-by: Arnd Bergmann List of files: /linux/security/Kconfig.hardening

f5c68a4e84f9feca3be578199ec648b676db2030 - hardening: Disable GCC randstruct for COMPILE_TEST

Wed, 09 Apr 2025 17:11:58 +0200

hardening: Disable GCC randstruct for COMPILE_TESTThere is a GCC crash bug in the randstruct for latest GCC versions thatis being tickled by landlock[1]. Temporarily disable GCC randstruct forCOMPILE_TEST builds to unbreak CI systems for the coming -rc2. This canbe restored once the bug is fixed.Suggested-by: Mark Brown Link: https://lore.kernel.org/all/20250407-kbuild-disable-gcc-plugins-v1-1-5d46ae583f5e@kernel.org/ [1]Acked-by: Mark Brown Acked-by: Arnd Bergmann Link: https://lore.kernel.org/r/20250409151154.work.872-kees@kernel.orgSigned-off-by: Kees Cook List of files: /linux/security/Kconfig.hardening

d70da12453ac3797e0c54884305ccc894e8c817b - hardening: Enable i386 FORTIFY_SOURCE on Clang 16+

Sat, 08 Mar 2025 05:29:26 +0100

hardening: Enable i386 FORTIFY_SOURCE on Clang 16+The i386 regparm bug exposed with FORTIFY_SOURCE with Clang was fixedin Clang 16[1].Link: https://github.com/llvm/llvm-project/commit/c167c0a4dcdb998affb2756ce76903a12f7d8ca5 [1]Reviewed-by: Nathan Chancellor Link: https://lore.kernel.org/r/20250308042929.1753543-2-kees@kernel.orgSigned-off-by: Kees Cook List of files: /linux/security/Kconfig.hardening

ca758b147e75f4b564225065d70b6526477185ce - fortify: Move FORTIFY_SOURCE under 'Kernel hardening options'

Thu, 23 Jan 2025 23:11:15 +0100

fortify: Move FORTIFY_SOURCE under 'Kernel hardening options'FORTIFY_SOURCE is a hardening option both at build and runtime. Moveit under 'Kernel hardening options'.Signed-off-by: Mel Gorman Acked-by: Paul Moore Link: https://lore.kernel.org/r/20250123221115.19722-5-mgorman@techsingularity.netSigned-off-by: Kees Cook List of files: /linux/security/Kconfig.hardening

d2132f453e3308adc82ab7c101bd5220a9a34167 - mm: security: Allow default HARDENED_USERCOPY to be set at compile time

Thu, 23 Jan 2025 23:11:13 +0100

mm: security: Allow default HARDENED_USERCOPY to be set at compile timeHARDENED_USERCOPY defaults to on if enabled at compile time. Allowhardened_usercopy= default to be set at compile time similar toinit_on_alloc= and init_on_free=. The intent is that hardeningoptions that can be disabled at runtime can set their default atbuild time.Signed-off-by: Mel Gorman Link: https://lore.kernel.org/r/20250123221115.19722-3-mgorman@techsingularity.netSigned-off-by: Kees Cook List of files: /linux/security/Kconfig.hardening

f4d4e8b9d6afe880a855e919c4ba4139455e11db - mm: security: Move hardened usercopy under 'Kernel hardening options'

Thu, 23 Jan 2025 23:11:12 +0100

mm: security: Move hardened usercopy under 'Kernel hardening options'There is a submenu for 'Kernel hardening options' under "Security".Move HARDENED_USERCOPY under the hardening options as it is clearlyrelated.Signed-off-by: Mel Gorman Acked-by: Paul Moore Link: https://lore.kernel.org/r/20250123221115.19722-2-mgorman@techsingularity.netSigned-off-by: Kees Cook List of files: /linux/security/Kconfig.hardening

a9a5e0bdc5a77a7c662ad4be0ad661f0b0d5e99d - hardening: Document INIT_STACK_ALL_PATTERN behavior with GCC

Tue, 07 Jan 2025 09:38:57 +0100

hardening: Document INIT_STACK_ALL_PATTERN behavior with GCCThe help text for INIT_STACK_ALL_PATTERN documents the patterns used byClang, but lacks documentation for GCC.Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/293d29d6a0d1823165be97285c1bc73e90ee9db8.1736239070.git.geert+renesas@glider.beSigned-off-by: Kees Cook List of files: /linux/security/Kconfig.hardening

dd3a7ee91e0ce0b03d22e974a79e8247cc99959b - hardening: Adjust dependencies in selection of MODVERSIONS

Sat, 28 Sep 2024 20:13:13 +0200

hardening: Adjust dependencies in selection of MODVERSIONSMODVERSIONS recently grew a dependency on !COMPILE_TEST so that Rustcould be more easily tested. However, this introduces a Kconfig warningwhen building allmodconfig with a clang version that supports RANDSTRUCTnatively because RANDSTRUCT_FULL and RANDSTRUCT_PERFORMANCE selectMODVERSIONS when MODULES is enabled, bypassing the !COMPILE_TESTdependency: WARNING: unmet direct dependencies detected for MODVERSIONS Depends on [n]: MODULES [=y] && !COMPILE_TEST [=y] Selected by [y]: - RANDSTRUCT_FULL [=y] && (CC_HAS_RANDSTRUCT [=y] || GCC_PLUGINS [=n]) && MODULES [=y]Add the !COMPILE_TEST dependency to the selections to clear up thewarning.Fixes: 1f9c4a996756 ("Kbuild: make MODVERSIONS support depend on not being a compile test build")Signed-off-by: Nathan Chancellor Link: https://lore.kernel.org/r/20240928-fix-randstruct-modversions-kconfig-warning-v1-1-27d3edc8571e@kernel.orgSigned-off-by: Kees Cook List of files: /linux/security/Kconfig.hardening

384a746bb55960aa5ffb3a67de08f11fc2f51042 - Revert "mm: init_mlocked_on_free_v3"

Wed, 05 Jun 2024 11:17:10 +0200

Revert "mm: init_mlocked_on_free_v3"There was insufficient review and no agreement that this is the rightapproach.There are serious flaws with the implementation that make processes usingmlock() not even work with simple fork() [1] and we get reliable crasheswhen rebooting.Further, simply because we might be unmapping a single PTE of a largemlocked folio, we shouldn't zero out the whole folio.... especially because the code can also *corrupt* urelated memory because kernel_init_pages(page, folio_nr_pages(folio));Could end up writing outside of the actual folio if we work with a tailpage.Let's revert it. Once there is agreement that this is the right approach,the issues were fixed and there was reasonable review and proper testing,we can consider it again.[1] https://lkml.kernel.org/r/4da9da2f-73e4-45fd-b62f-a8a513314057@redhat.comLink: https://lkml.kernel.org/r/20240605091710.38961-1-david@redhat.comFixes: ba42b524a040 ("mm: init_mlocked_on_free_v3")Signed-off-by: David Hildenbrand Reported-by: David Wang <00107082@163.com>Closes: https://lore.kernel.org/lkml/20240528151340.4282-1-00107082@163.com/Reported-by: Lance Yang Closes: https://lkml.kernel.org/r/20240601140917.43562-1-ioworker0@gmail.comAcked-by: Lance Yang Cc: York Jasper Niebuhr Cc: Matthew Wilcox (Oracle) Cc: Kees Cook Signed-off-by: Andrew Morton List of files: /linux/security/Kconfig.hardening

ba42b524a0408b5f92bd41edaee1ea84309ab9ae - mm: init_mlocked_on_free_v3

Fri, 29 Mar 2024 15:56:05 +0100

mm: init_mlocked_on_free_v3Implements the "init_mlocked_on_free" boot option. When this boot optionis enabled, any mlock'ed pages are zeroed on free. Ifthe pages are munlock'ed beforehand, no initialization takes place.This boot option is meant to combat the performance hit of"init_on_free" as reported in commit 6471384af2a6 ("mm: security:introduce init_on_alloc=1 and init_on_free=1 boot options"). With"init_mlocked_on_free=1" only relevant data is freed while everythingelse is left untouched by the kernel. Correspondingly, this patchintroduces no performance hit for unmapping non-mlock'ed memory. Theunmapping overhead for purely mlocked memory was measured to beapproximately 13%. Realistically, most systems mlock only a fraction ofthe total memory so the real-world system overhead should be close tozero.Optimally, userspace programs clear any key material or otherconfidential memory before exit and munlock the according memoryregions. If a program crashes, userspace key managers fail to do thisjob. Accordingly, no munlock operations are performed so the data iscaught and zeroed by the kernel. Should the program not crash, allmemory will ideally be munlocked so no overhead is caused.CONFIG_INIT_MLOCKED_ON_FREE_DEFAULT_ON can be set to enable"init_mlocked_on_free" by default.Link: https://lkml.kernel.org/r/20240329145605.149917-1-yjnworkstation@gmail.comSigned-off-by: York Jasper Niebuhr Cc: Matthew Wilcox (Oracle) Cc: York Jasper Niebuhr Cc: Kees Cook Signed-off-by: Andrew Morton List of files: /linux/security/Kconfig.hardening

aa9f10d57056cea51d41283d3785bccbbb9f459e - hardening: Move BUG_ON_DATA_CORRUPTION to hardening options

Fri, 11 Aug 2023 17:18:41 +0200

hardening: Move BUG_ON_DATA_CORRUPTION to hardening optionsBUG_ON_DATA_CORRUPTION is turning detected corruptions of list datastructures from WARNings into BUGs. This can be useful to stop furthercorruptions or even exploitation attempts.However, the option has less to do with debugging than with hardening.With the introduction of LIST_HARDENED, it makes more sense to move itto the hardening options, where it selects LIST_HARDENED instead.Without this change, combining BUG_ON_DATA_CORRUPTION with LIST_HARDENEDalone wouldn't be possible, because DEBUG_LIST would always be selectedby BUG_ON_DATA_CORRUPTION.Signed-off-by: Marco Elver Link: https://lore.kernel.org/r/20230811151847.1594958-4-elver@google.comSigned-off-by: Kees Cook List of files: /linux/security/Kconfig.hardening