Quellcodebibliothek Statistik Leitseite products/sources/formale Sprachen/C/Linux/lib/   (Open Source Betriebssystem Version 6.17.9©)  Datei vom 24.10.2025 mit Größe 7 kB image not shown  

Quelle  Kconfig.kasan   Sprache: unbekannt

 
Spracherkennung für: .kasan vermutete Sprache: Unknown {[0] [0] [0]} [Methode: Schwerpunktbildung, einfache Gewichte, sechs Dimensionen]

# SPDX-License-Identifier: GPL-2.0-only

# This config refers to the generic KASAN mode.
config HAVE_ARCH_KASAN
 bool

config HAVE_ARCH_KASAN_SW_TAGS
 bool

config HAVE_ARCH_KASAN_HW_TAGS
 bool

config HAVE_ARCH_KASAN_VMALLOC
 bool

config ARCH_DISABLE_KASAN_INLINE
 bool
 help
   Disables both inline and stack instrumentation. Selected by
   architectures that do not support these instrumentation types.

config CC_HAS_KASAN_GENERIC
 def_bool $(cc-option, -fsanitize=kernel-address)

config CC_HAS_KASAN_SW_TAGS
 def_bool $(cc-option, -fsanitize=kernel-hwaddress)

# This option is only required for software KASAN modes.
# Old GCC versions do not have proper support for no_sanitize_address.
# See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89124 for details.
config CC_HAS_WORKING_NOSANITIZE_ADDRESS
 def_bool !CC_IS_GCC || GCC_VERSION >= 80300

menuconfig KASAN
 bool "KASAN: dynamic memory safety error detector"
 depends on (((HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC) || \
       (HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS)) && \
      CC_HAS_WORKING_NOSANITIZE_ADDRESS) || \
     HAVE_ARCH_KASAN_HW_TAGS
 depends on SYSFS && !SLUB_TINY
 select STACKDEPOT_ALWAYS_INIT
 help
   Enables KASAN (Kernel Address Sanitizer) - a dynamic memory safety
   error detector designed to find out-of-bounds and use-after-free bugs.

   See Documentation/dev-tools/kasan.rst for details.

   For better error reports, also enable CONFIG_STACKTRACE.

if KASAN

config CC_HAS_KASAN_MEMINTRINSIC_PREFIX
 def_bool (CC_IS_CLANG && $(cc-option,-fsanitize=kernel-address -mllvm -asan-kernel-mem-intrinsic-prefix=1)) || \
   (CC_IS_GCC && $(cc-option,-fsanitize=kernel-address --param asan-kernel-mem-intrinsic-prefix=1))
 # Don't define it if we don't need it: compilation of the test uses
 # this variable to decide how the compiler should treat builtins.
 depends on !KASAN_HW_TAGS
 help
   The compiler is able to prefix memintrinsics with __asan or __hwasan.

choice
 prompt "KASAN mode"
 default KASAN_GENERIC
 help
   KASAN has three modes:

   1. Generic KASAN (supported by many architectures, enabled with
      CONFIG_KASAN_GENERIC, similar to userspace ASan),
   2. Software Tag-Based KASAN (arm64 only, based on software memory
      tagging, enabled with CONFIG_KASAN_SW_TAGS, similar to userspace
      HWASan), and
   3. Hardware Tag-Based KASAN (arm64 only, based on hardware memory
      tagging, enabled with CONFIG_KASAN_HW_TAGS).

   See Documentation/dev-tools/kasan.rst for details about each mode.

config KASAN_GENERIC
 bool "Generic KASAN"
 depends on HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC
 depends on CC_HAS_WORKING_NOSANITIZE_ADDRESS
 select SLUB_DEBUG
 select CONSTRUCTORS
 help
   Enables Generic KASAN.

   Requires GCC 8.3.0+ or Clang.

   Consumes about 1/8th of available memory at kernel start and adds an
   overhead of ~50% for dynamic allocations.
   The performance slowdown is ~x3.

config KASAN_SW_TAGS
 bool "Software Tag-Based KASAN"
 depends on HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS
 depends on CC_HAS_WORKING_NOSANITIZE_ADDRESS
 select SLUB_DEBUG
 select CONSTRUCTORS
 help
   Enables Software Tag-Based KASAN.

   Requires GCC 11+ or Clang.

   Supported only on arm64 CPUs and relies on Top Byte Ignore.

   Consumes about 1/16th of available memory at kernel start and
   add an overhead of ~20% for dynamic allocations.

   May potentially introduce problems related to pointer casting and
   comparison, as it embeds a tag into the top byte of each pointer.

config KASAN_HW_TAGS
 bool "Hardware Tag-Based KASAN"
 depends on HAVE_ARCH_KASAN_HW_TAGS
 help
   Enables Hardware Tag-Based KASAN.

   Requires GCC 10+ or Clang 12+.

   Supported only on arm64 CPUs starting from ARMv8.5 and relies on
   Memory Tagging Extension and Top Byte Ignore.

   Consumes about 1/32nd of available memory.

   May potentially introduce problems related to pointer casting and
   comparison, as it embeds a tag into the top byte of each pointer.

endchoice

choice
 prompt "Instrumentation type"
 depends on KASAN_GENERIC || KASAN_SW_TAGS
 default KASAN_INLINE if !ARCH_DISABLE_KASAN_INLINE

config KASAN_OUTLINE
 bool "Outline instrumentation"
 help
   Makes the compiler insert function calls that check whether the memory
   is accessible before each memory access. Slower than KASAN_INLINE, but
   does not bloat the size of the kernel's .text section so much.

config KASAN_INLINE
 bool "Inline instrumentation"
 depends on !ARCH_DISABLE_KASAN_INLINE
 help
   Makes the compiler directly insert memory accessibility checks before
   each memory access. Faster than KASAN_OUTLINE (gives ~x2 boost for
   some workloads), but makes the kernel's .text size much bigger.

endchoice

config KASAN_STACK
 bool "Stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
 depends on KASAN_GENERIC || KASAN_SW_TAGS
 depends on !ARCH_DISABLE_KASAN_INLINE
 default y if CC_IS_GCC
 help
   Disables stack instrumentation and thus KASAN's ability to detect
   out-of-bounds bugs in stack variables.

   With Clang, stack instrumentation has a problem that causes excessive
   stack usage, see https://llvm.org/pr38809. Thus,
   with Clang, this option is deemed unsafe.

   This option is always disabled when compile-testing with Clang to
   avoid cluttering the log with stack overflow warnings.

   With GCC, enabling stack instrumentation is assumed to be safe.

   If the architecture disables inline instrumentation via
   ARCH_DISABLE_KASAN_INLINE, stack instrumentation gets disabled
   as well, as it adds inline-style instrumentation that is run
   unconditionally.

config KASAN_VMALLOC
 bool "Check accesses to vmalloc allocations"
 depends on HAVE_ARCH_KASAN_VMALLOC
 help
   Makes KASAN check the validity of accesses to vmalloc allocations.

   With software KASAN modes, all types vmalloc allocations are
   checked. Enabling this option leads to higher memory usage.

   With Hardware Tag-Based KASAN, only non-executable VM_ALLOC mappings
   are checked. There is no additional memory usage.

config KASAN_KUNIT_TEST
 tristate "KUnit-compatible tests of KASAN bug detection capabilities" if !KUNIT_ALL_TESTS
 depends on KASAN && KUNIT && TRACEPOINTS
 default KUNIT_ALL_TESTS
 help
   A KUnit-based KASAN test suite. Triggers different kinds of
   out-of-bounds and use-after-free accesses. Useful for testing whether
   KASAN can detect certain bug types.

   For more information on KUnit and unit tests in general, please refer
   to the KUnit documentation in Documentation/dev-tools/kunit/.

config KASAN_EXTRA_INFO
 bool "Record and report more information"
 depends on KASAN
 help
   Record and report more information to help us find the cause of the
   bug and to help us correlate the error with other system events.

   Currently, the CPU number and timestamp are additionally
   recorded for each heap block at allocation and free time, and
   8 bytes will be added to each metadata structure that records
   allocation or free information.

   In Generic KASAN, each kmalloc-8 and kmalloc-16 object will add
   16 bytes of additional memory consumption, and each kmalloc-32
   object will add 8 bytes of additional memory consumption, not
   affecting other larger objects.

   In SW_TAGS KASAN and HW_TAGS KASAN, depending on the stack_ring_size
   boot parameter, it will add 8 * stack_ring_size bytes of additional
   memory consumption.

endif # KASAN

[ Dauer der Verarbeitung: 0.38 Sekunden  ]