security/Kconfig.hardening
Source file repositories/reference/linux-study-clean/security/Kconfig.hardening
File Facts
- System
- Linux kernel
- Corpus path
security/Kconfig.hardening- Extension
.hardening- Size
- 13652 bytes
- Lines
- 350
- Domain
- Core OS
- Bucket
- Security And Isolation
- Inferred role
- Core OS: Security And Isolation
- Status
- atlas-only
Why This File Exists
Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.
- Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.
- Touches user memory; correctness depends on fault-safe copying and privilege boundary handling.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
# SPDX-License-Identifier: GPL-2.0-only
menu "Kernel hardening options"
menu "Memory initialization"
config CC_HAS_AUTO_VAR_INIT_PATTERN
def_bool $(cc-option,-ftrivial-auto-var-init=pattern)
config CC_HAS_AUTO_VAR_INIT_ZERO_BARE
def_bool $(cc-option,-ftrivial-auto-var-init=zero)
config CC_HAS_AUTO_VAR_INIT_ZERO_ENABLER
# Clang 16 and later warn about using the -enable flag, but it
# is required before then.
def_bool $(cc-option,-ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang)
depends on !CC_HAS_AUTO_VAR_INIT_ZERO_BARE
config CC_HAS_AUTO_VAR_INIT_ZERO
def_bool CC_HAS_AUTO_VAR_INIT_ZERO_BARE || CC_HAS_AUTO_VAR_INIT_ZERO_ENABLER
choice
prompt "Initialize kernel stack variables at function entry"
default INIT_STACK_ALL_PATTERN if COMPILE_TEST && CC_HAS_AUTO_VAR_INIT_PATTERN
default INIT_STACK_ALL_ZERO if CC_HAS_AUTO_VAR_INIT_ZERO
default INIT_STACK_NONE
help
This option enables initialization of stack variables at
function entry time. This has the possibility to have the
greatest coverage (since all functions can have their
variables initialized), but the performance impact depends
on the function calling complexity of a given workload's
syscalls.
This chooses the level of coverage over classes of potentially
uninitialized variables. The selected class of variable will be
initialized before use in a function.
config INIT_STACK_NONE
bool "no automatic stack variable initialization (weakest)"
help
Disable automatic stack variable initialization.
This leaves the kernel vulnerable to the standard
classes of uninitialized stack variable exploits
and information exposures.
config INIT_STACK_ALL_PATTERN
bool "pattern-init everything (strongest)"
depends on CC_HAS_AUTO_VAR_INIT_PATTERN
depends on !KMSAN
help
Initializes everything on the stack (including padding)
with a specific debug value. This is intended to eliminate
all classes of uninitialized stack variable exploits and
information exposures, even variables that were warned about
having been left uninitialized.
Pattern initialization is known to provoke many existing bugs
related to uninitialized locals, e.g. pointers receive
non-NULL values, buffer sizes and indices are very big. The
pattern is situation-specific; Clang on 64-bit uses 0xAA
repeating for all types and padding except float and double
which use 0xFF repeating (-NaN). Clang on 32-bit uses 0xFF
repeating for all types and padding.
GCC uses 0xFE repeating for all types, and zero for padding.
config INIT_STACK_ALL_ZERO
bool "zero-init everything (strongest and safest)"
depends on CC_HAS_AUTO_VAR_INIT_ZERO
depends on !KMSAN
help
Annotation
- Atlas domain: Core OS / Security And Isolation.
- Implementation status: atlas-only.
- This snippet crosses the user/kernel memory boundary; validate fault handling and access checks before translating the pattern.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.