mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-21 15:59:33 +07:00
e7c52b84fb
We get a lot of very large stack frames using gcc-7.0.1 with the default -fsanitize-address-use-after-scope --param asan-stack=1 options, which can easily cause an overflow of the kernel stack, e.g. drivers/gpu/drm/i915/gvt/handlers.c:2434:1: warning: the frame size of 46176 bytes is larger than 3072 bytes drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5650:1: warning: the frame size of 23632 bytes is larger than 3072 bytes lib/atomic64_test.c:250:1: warning: the frame size of 11200 bytes is larger than 3072 bytes drivers/gpu/drm/i915/gvt/handlers.c:2621:1: warning: the frame size of 9208 bytes is larger than 3072 bytes drivers/media/dvb-frontends/stv090x.c:3431:1: warning: the frame size of 6816 bytes is larger than 3072 bytes fs/fscache/stats.c:287:1: warning: the frame size of 6536 bytes is larger than 3072 bytes To reduce this risk, -fsanitize-address-use-after-scope is now split out into a separate CONFIG_KASAN_EXTRA Kconfig option, leading to stack frames that are smaller than 2 kilobytes most of the time on x86_64. An earlier version of this patch also prevented combining KASAN_EXTRA with KASAN_INLINE, but that is no longer necessary with gcc-7.0.1. All patches to get the frame size below 2048 bytes with CONFIG_KASAN=y and CONFIG_KASAN_EXTRA=n have been merged by maintainers now, so we can bring back that default now. KASAN_EXTRA=y still causes lots of warnings but now defaults to !COMPILE_TEST to disable it in allmodconfig, and it remains disabled in all other defconfigs since it is a new option. I arbitrarily raise the warning limit for KASAN_EXTRA to 3072 to reduce the noise, but an allmodconfig kernel still has around 50 warnings on gcc-7. I experimented a bit more with smaller stack frames and have another follow-up series that reduces the warning limit for 64-bit architectures to 1280 bytes (without CONFIG_KASAN). With earlier versions of this patch series, I also had patches to address the warnings we get with KASAN and/or KASAN_EXTRA, using a "noinline_if_stackbloat" annotation. That annotation now got replaced with a gcc-8 bugfix (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715) and a workaround for older compilers, which means that KASAN_EXTRA is now just as bad as before and will lead to an instant stack overflow in a few extreme cases. This reverts parts of commit3f181b4d86("lib/Kconfig.debug: disable -Wframe-larger-than warnings with KASAN=y"). Two patches in linux-next should be merged first to avoid introducing warnings in an allmodconfig build:3cd890dbe2("media: dvb-frontends: fix i2c access helpers for KASAN")16c3ada89c("media: r820t: fix r820t_write_reg for KASAN") Do we really need to backport this? I think we do: without this patch, enabling KASAN will lead to unavoidable kernel stack overflow in certain device drivers when built with gcc-7 or higher on linux-4.10+ or any version that contains a backport of commitc5caf21ab0. Most people are probably still on older compilers, but it will get worse over time as they upgrade their distros. The warnings we get on kernels older than this should all be for code that uses dangerously large stack frames, though most of them do not cause an actual stack overflow by themselves.The asan-stack option was added in linux-4.0, and commit3f181b4d86("lib/Kconfig.debug: disable -Wframe-larger-than warnings with KASAN=y") effectively turned off the warning for allmodconfig kernels, so I would like to see this fix backported to any kernels later than 4.0. I have done dozens of fixes for individual functions with stack frames larger than 2048 bytes with asan-stack, and I plan to make sure that all those fixes make it into the stable kernels as well (most are already there). Part of the complication here is that asan-stack (from 4.0) was originally assumed to always require much larger stacks, but that turned out to be a combination of multiple gcc bugs that we have now worked around and fixed, but sanitize-address-use-after-scope (from v4.10) has a much higher inherent stack usage and also suffers from at least three other problems that we have analyzed but not yet fixed upstream, each of them makes the stack usage more severe than it should be. Link: http://lkml.kernel.org/r/20171221134744.2295529-1-arnd@arndb.de Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Andrey Konovalov <andreyknvl@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
68 lines
2.2 KiB
Plaintext
68 lines
2.2 KiB
Plaintext
config HAVE_ARCH_KASAN
|
|
bool
|
|
|
|
if HAVE_ARCH_KASAN
|
|
|
|
config KASAN
|
|
bool "KASan: runtime memory debugger"
|
|
depends on SLUB || (SLAB && !DEBUG_SLAB)
|
|
select CONSTRUCTORS
|
|
select STACKDEPOT
|
|
help
|
|
Enables kernel address sanitizer - runtime memory debugger,
|
|
designed to find out-of-bounds accesses and use-after-free bugs.
|
|
This is strictly a debugging feature and it requires a gcc version
|
|
of 4.9.2 or later. Detection of out of bounds accesses to stack or
|
|
global variables requires gcc 5.0 or later.
|
|
This feature consumes about 1/8 of available memory and brings about
|
|
~x3 performance slowdown.
|
|
For better error detection enable CONFIG_STACKTRACE.
|
|
Currently CONFIG_KASAN doesn't work with CONFIG_DEBUG_SLAB
|
|
(the resulting kernel does not boot).
|
|
|
|
config KASAN_EXTRA
|
|
bool "KAsan: extra checks"
|
|
depends on KASAN && DEBUG_KERNEL && !COMPILE_TEST
|
|
help
|
|
This enables further checks in the kernel address sanitizer, for now
|
|
it only includes the address-use-after-scope check that can lead
|
|
to excessive kernel stack usage, frame size warnings and longer
|
|
compile time.
|
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 has more
|
|
|
|
|
|
choice
|
|
prompt "Instrumentation type"
|
|
depends on KASAN
|
|
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"
|
|
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.
|
|
This requires a gcc version of 5.0 or later.
|
|
|
|
endchoice
|
|
|
|
config TEST_KASAN
|
|
tristate "Module for testing kasan for bug detection"
|
|
depends on m && KASAN
|
|
help
|
|
This is a test module doing various nasty things like
|
|
out of bounds accesses, use after free. It is useful for testing
|
|
kernel debugging features like kernel address sanitizer.
|
|
|
|
endif
|