lib/Kconfig.ubsan
Source file repositories/reference/linux-study-clean/lib/Kconfig.ubsan
File Facts
- System
- Linux kernel
- Corpus path
lib/Kconfig.ubsan- Extension
.ubsan- Size
- 7192 bytes
- Lines
- 180
- Domain
- Kernel Services
- Bucket
- lib
- Inferred role
- Kernel Services: lib
- Status
- atlas-only
Why This File Exists
Shared kernel service surface used by multiple subsystems, including helpers, cryptography, virtualization support, and async I/O infrastructure.
- Shared kernel service surface used by multiple subsystems, including helpers, cryptography, virtualization support, and async I/O infrastructure.
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
config ARCH_HAS_UBSAN
bool
menuconfig UBSAN
bool "Undefined behaviour sanity checker"
depends on ARCH_HAS_UBSAN
help
This option enables the Undefined Behaviour sanity checker.
Compile-time instrumentation is used to detect various undefined
behaviours at runtime. For more details, see:
Documentation/dev-tools/ubsan.rst
if UBSAN
config UBSAN_TRAP
bool "Abort on Sanitizer warnings (smaller kernel but less verbose)"
depends on !COMPILE_TEST
help
Building kernels with Sanitizer features enabled tends to grow
the kernel size by around 5%, due to adding all the debugging
text on failure paths. To avoid this, Sanitizer instrumentation
can just issue a trap. This reduces the kernel size overhead but
turns all warnings (including potentially harmless conditions)
into full exceptions that abort the running kernel code
(regardless of context, locks held, etc), which may destabilize
the system. For some system builders this is an acceptable
trade-off.
Also note that selecting Y will cause your kernel to Oops
with an "illegal instruction" error with no further details
when a UBSAN violation occurs. (Except on arm64 and x86, which
will report which Sanitizer failed.) This may make it hard to
determine whether an Oops was caused by UBSAN or to figure
out the details of a UBSAN violation. It makes the kernel log
output less useful for bug reports.
config CC_HAS_UBSAN_BOUNDS_STRICT
def_bool $(cc-option,-fsanitize=bounds-strict)
help
The -fsanitize=bounds-strict option is only available on GCC,
but uses the more strict handling of arrays that includes knowledge
of flexible arrays, which is comparable to Clang's regular
-fsanitize=bounds.
config CC_HAS_UBSAN_ARRAY_BOUNDS
def_bool $(cc-option,-fsanitize=array-bounds)
help
Under Clang, the -fsanitize=bounds option is actually composed
of two more specific options, -fsanitize=array-bounds and
-fsanitize=local-bounds. However, -fsanitize=local-bounds can
only be used when trap mode is enabled. (See also the help for
CONFIG_LOCAL_BOUNDS.) Explicitly check for -fsanitize=array-bounds
so that we can build up the options needed for UBSAN_BOUNDS
with or without UBSAN_TRAP.
config UBSAN_BOUNDS
bool "Perform array index bounds checking"
default UBSAN
depends on CC_HAS_UBSAN_ARRAY_BOUNDS || CC_HAS_UBSAN_BOUNDS_STRICT
help
This option enables detection of directly indexed out of bounds
array accesses, where the array size is known at compile time.
Note that this does not protect array overflows via bad calls
to the {str,mem}*cpy() family of functions (that is addressed
by CONFIG_FORTIFY_SOURCE).
config UBSAN_BOUNDS_STRICT
def_bool UBSAN_BOUNDS && CC_HAS_UBSAN_BOUNDS_STRICT
help
Annotation
- Atlas domain: Kernel Services / lib.
- Implementation status: atlas-only.
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.