From 2c3c1048746a4622d8c89a29670120dc8fab93c4 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sun, 7 Apr 2024 20:49:45 +0200 Subject: Adding upstream version 6.1.76. Signed-off-by: Daniel Baumann --- lib/Kconfig.kasan | 201 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 201 insertions(+) create mode 100644 lib/Kconfig.kasan (limited to 'lib/Kconfig.kasan') diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan new file mode 100644 index 000000000..ca09b1cf8 --- /dev/null +++ b/lib/Kconfig.kasan @@ -0,0 +1,201 @@ +# 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 (SLUB && SYSFS) || (SLAB && !DEBUG_SLAB) + 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 + +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 if SLUB + 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. + + (Incompatible with CONFIG_DEBUG_SLAB: the kernel does not boot.) + +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 if SLUB + 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. + + (Incompatible with CONFIG_DEBUG_SLAB: the kernel does not boot.) + +config KASAN_HW_TAGS + bool "Hardware Tag-Based KASAN" + depends on HAVE_ARCH_KASAN_HW_TAGS + depends on SLUB + 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_OUTLINE + +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://bugs.llvm.org/show_bug.cgi?id=38809. 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 + 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_MODULE_TEST + tristate "KUnit-incompatible tests of KASAN bug detection capabilities" + depends on m && KASAN && !KASAN_HW_TAGS + help + A part of the KASAN test suite that is not integrated with KUnit. + Incompatible with Hardware Tag-Based KASAN. + +endif # KASAN -- cgit v1.2.3