mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2024-11-25 05:04:09 +08:00
7a22bdc3c4
Add memory corruption identification support for hardware tag-based mode. We store one old free pointer tag and free backtrace instead of five because hardware tag-based kasan only has 16 different tags. If we store as many stacks as SW tag-based kasan does(5 stacks), there is high probability to find the same tag in the stacks when out-of-bound issues happened and we will mistake out-of-bound issue for use-after-free. Link: https://lkml.kernel.org/r/20210626100931.22794-4-Kuan-Ying.Lee@mediatek.com Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com> Suggested-by: Marco Elver <elver@google.com> Reviewed-by: Alexander Potapenko <glider@google.com> Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com> Reviewed-by: Marco Elver <elver@google.com> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Chinwen Chang <chinwen.chang@mediatek.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Nicholas Tang <nicholas.tang@mediatek.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
212 lines
7.2 KiB
Plaintext
212 lines
7.2 KiB
Plaintext
# 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
|
|
An architecture might not support inline instrumentation.
|
|
When this option is selected, inline and stack instrumentation are
|
|
disabled.
|
|
|
|
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 don't 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: runtime memory debugger"
|
|
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
|
|
help
|
|
Enables KASAN (KernelAddressSANitizer) - runtime memory debugger,
|
|
designed to find out-of-bounds accesses and use-after-free bugs.
|
|
See Documentation/dev-tools/kasan.rst for details.
|
|
|
|
if KASAN
|
|
|
|
choice
|
|
prompt "KASAN mode"
|
|
default KASAN_GENERIC
|
|
help
|
|
KASAN has three modes:
|
|
1. generic KASAN (similar to userspace ASan,
|
|
x86_64/arm64/xtensa, enabled with CONFIG_KASAN_GENERIC),
|
|
2. software tag-based KASAN (arm64 only, based on software
|
|
memory tagging (similar to userspace HWASan), enabled with
|
|
CONFIG_KASAN_SW_TAGS), and
|
|
3. hardware tag-based KASAN (arm64 only, based on hardware
|
|
memory tagging, enabled with CONFIG_KASAN_HW_TAGS).
|
|
|
|
All KASAN modes are strictly debugging features.
|
|
|
|
For better error reports enable CONFIG_STACKTRACE.
|
|
|
|
config KASAN_GENERIC
|
|
bool "Generic mode"
|
|
depends on HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC
|
|
select SLUB_DEBUG if SLUB
|
|
select CONSTRUCTORS
|
|
help
|
|
Enables generic KASAN mode.
|
|
|
|
This mode is supported in both GCC and Clang. With GCC it requires
|
|
version 8.3.0 or later. Any supported Clang version is compatible,
|
|
but detection of out-of-bounds accesses for global variables is
|
|
supported only since Clang 11.
|
|
|
|
This mode consumes about 1/8th of available memory at kernel start
|
|
and introduces an overhead of ~x1.5 for the rest of the allocations.
|
|
The performance slowdown is ~x3.
|
|
|
|
Currently CONFIG_KASAN_GENERIC doesn't work with CONFIG_DEBUG_SLAB
|
|
(the resulting kernel does not boot).
|
|
|
|
config KASAN_SW_TAGS
|
|
bool "Software tag-based mode"
|
|
depends on HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS
|
|
select SLUB_DEBUG if SLUB
|
|
select CONSTRUCTORS
|
|
help
|
|
Enables software tag-based KASAN mode.
|
|
|
|
This mode require software memory tagging support in the form of
|
|
HWASan-like compiler instrumentation.
|
|
|
|
Currently this mode is only implemented for arm64 CPUs and relies on
|
|
Top Byte Ignore. This mode requires Clang.
|
|
|
|
This mode consumes about 1/16th of available memory at kernel start
|
|
and introduces an overhead of ~20% for the rest of the allocations.
|
|
This mode may potentially introduce problems relating to pointer
|
|
casting and comparison, as it embeds tags into the top byte of each
|
|
pointer.
|
|
|
|
Currently CONFIG_KASAN_SW_TAGS doesn't work with CONFIG_DEBUG_SLAB
|
|
(the resulting kernel does not boot).
|
|
|
|
config KASAN_HW_TAGS
|
|
bool "Hardware tag-based mode"
|
|
depends on HAVE_ARCH_KASAN_HW_TAGS
|
|
depends on SLUB
|
|
help
|
|
Enables hardware tag-based KASAN mode.
|
|
|
|
This mode requires hardware memory tagging support, and can be used
|
|
by any architecture that provides it.
|
|
|
|
Currently this mode is only implemented for arm64 CPUs starting from
|
|
ARMv8.5 and relies on Memory Tagging Extension and Top Byte Ignore.
|
|
|
|
endchoice
|
|
|
|
choice
|
|
prompt "Instrumentation type"
|
|
depends on KASAN_GENERIC || KASAN_SW_TAGS
|
|
default KASAN_OUTLINE
|
|
|
|
config KASAN_OUTLINE
|
|
bool "Outline instrumentation"
|
|
help
|
|
Before every memory access compiler insert function call
|
|
__asan_load*/__asan_store*. These functions performs check
|
|
of shadow memory. This is slower than inline instrumentation,
|
|
however it doesn't bloat size of kernel's .text section so
|
|
much as inline does.
|
|
|
|
config KASAN_INLINE
|
|
bool "Inline instrumentation"
|
|
depends on !ARCH_DISABLE_KASAN_INLINE
|
|
help
|
|
Compiler directly inserts code checking shadow memory before
|
|
memory accesses. This is faster than outline (in some workloads
|
|
it gives about x2 boost over outline instrumentation), but
|
|
make kernel's .text size much bigger.
|
|
|
|
endchoice
|
|
|
|
config KASAN_STACK
|
|
bool "Enable 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
|
|
The LLVM stack address sanitizer has a know problem that
|
|
causes excessive stack usage in a lot of functions, see
|
|
https://bugs.llvm.org/show_bug.cgi?id=38809
|
|
Disabling asan-stack makes it safe to run kernels build
|
|
with clang-8 with KASAN enabled, though it loses some of
|
|
the functionality.
|
|
This feature is always disabled when compile-testing with clang
|
|
to avoid cluttering the output in stack overflow warnings,
|
|
but clang users can still enable it for builds without
|
|
CONFIG_COMPILE_TEST. On gcc it is assumed to always be safe
|
|
to use and enabled by default.
|
|
If the architecture disables inline instrumentation, stack
|
|
instrumentation is also disabled as it adds inline-style
|
|
instrumentation that is run unconditionally.
|
|
|
|
config KASAN_TAGS_IDENTIFY
|
|
bool "Enable memory corruption identification"
|
|
depends on KASAN_SW_TAGS || KASAN_HW_TAGS
|
|
help
|
|
This option enables best-effort identification of bug type
|
|
(use-after-free or out-of-bounds) at the cost of increased
|
|
memory consumption.
|
|
|
|
config KASAN_VMALLOC
|
|
bool "Back mappings in vmalloc space with real shadow memory"
|
|
depends on KASAN_GENERIC && HAVE_ARCH_KASAN_VMALLOC
|
|
help
|
|
By default, the shadow region for vmalloc space is the read-only
|
|
zero page. This means that KASAN cannot detect errors involving
|
|
vmalloc space.
|
|
|
|
Enabling this option will hook in to vmap/vmalloc and back those
|
|
mappings with real shadow memory allocated on demand. This allows
|
|
for KASAN to detect more sorts of errors (and to support vmapped
|
|
stacks), but at the cost of higher 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
|
|
This is a KUnit test suite doing various nasty things like
|
|
out of bounds and use after free accesses. It is useful for testing
|
|
kernel debugging features like KASAN.
|
|
|
|
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
|
|
This is a part of the KASAN test suite that is incompatible with
|
|
KUnit. Currently includes tests that do bad copy_from/to_user
|
|
accesses.
|
|
|
|
endif # KASAN
|