scripts/Makefile.kasan
Source file repositories/reference/linux-study-clean/scripts/Makefile.kasan
File Facts
- System
- Linux kernel
- Corpus path
scripts/Makefile.kasan- Extension
.kasan- Size
- 3712 bytes
- Lines
- 107
- Domain
- Support Tooling And Documentation
- Bucket
- scripts
- Inferred role
- Support Tooling And Documentation: build/configuration rule
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
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
ifdef CONFIG_CC_HAS_KASAN_MEMINTRINSIC_PREFIX
# Safe for compiler to generate meminstrinsic calls in uninstrumented files.
CFLAGS_KASAN_NOSANITIZE :=
else
# Don't let compiler generate memintrinsic calls in uninstrumented files
# because they are instrumented.
CFLAGS_KASAN_NOSANITIZE := -fno-builtin
endif
KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET)
cc-param = $(call cc-option, -mllvm -$(1), $(call cc-option, --param $(1)))
rustc-param = $(call rustc-option, -Cllvm-args=-$(1),)
check-args = $(foreach arg,$(2),$(call $(1),$(arg)))
kasan_params :=
ifdef CONFIG_KASAN_STACK
stack_enable := 1
else
stack_enable := 0
endif
ifdef CONFIG_KASAN_GENERIC
ifdef CONFIG_KASAN_INLINE
# When the number of memory accesses in a function is less than this
# call threshold number, the compiler will use inline instrumentation.
# 10000 is chosen offhand as a sufficiently large number to make all
# kernel functions to be instrumented inline.
call_threshold := 10000
else
call_threshold := 0
endif
# First, enable -fsanitize=kernel-address together with providing the shadow
# mapping offset, as for GCC, -fasan-shadow-offset fails without -fsanitize
# (GCC accepts the shadow mapping offset via -fasan-shadow-offset instead of
# a --param like the other KASAN parameters).
# Instead of ifdef-checking the compiler, rely on cc-option.
CFLAGS_KASAN := $(call cc-option, -fsanitize=kernel-address \
-fasan-shadow-offset=$(KASAN_SHADOW_OFFSET), \
$(call cc-option, -fsanitize=kernel-address \
-mllvm -asan-mapping-offset=$(KASAN_SHADOW_OFFSET)))
# The minimum supported `rustc` version has a minimum supported LLVM
# version late enough that we can assume support for -asan-mapping-offset.
RUSTFLAGS_KASAN := -Zsanitizer=kernel-address \
-Zsanitizer-recover=kernel-address \
-Cllvm-args=-asan-mapping-offset=$(KASAN_SHADOW_OFFSET)
# Now, add other parameters enabled similarly in GCC, Clang, and rustc.
# As some of them are not supported by older compilers, these will be filtered
# through `cc-param` or `rust-param` as applicable.
kasan_params += asan-instrumentation-with-call-threshold=$(call_threshold) \
asan-stack=$(stack_enable) \
asan-instrument-allocas=1 \
asan-globals=1
# Instrument memcpy/memset/memmove calls by using instrumented __asan_mem*()
# instead. With compilers that don't support this option, compiler-inserted
# memintrinsics won't be checked by KASAN on GENERIC_ENTRY architectures.
kasan_params += asan-kernel-mem-intrinsic-prefix=1
endif # CONFIG_KASAN_GENERIC
ifdef CONFIG_KASAN_SW_TAGS
Annotation
- Atlas domain: Support Tooling And Documentation / scripts.
- 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.