2019-05-19 05:07:45 -07:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
2024-01-28 11:45:29 -07:00
|
|
|
config ARCH_HAS_UBSAN
|
2016-01-20 16:00:55 -07:00
|
|
|
bool
|
|
|
|
|
|
ubsan: split "bounds" checker from other options
In order to do kernel builds with the bounds checker individually
available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under
CONFIG_UBSAN_MISC.
For example, using this, we can start to expand the coverage syzkaller is
providing. Right now, all of UBSan is disabled for syzbot builds because
taken as a whole, it is too noisy. This will let us focus on one feature
at a time.
For the bounds checker specifically, this provides a mechanism to
eliminate an entire class of array overflows with close to zero
performance overhead (I cannot measure a difference). In my (mostly)
defconfig, enabling bounds checking adds ~4200 checks to the kernel.
Performance changes are in the noise, likely due to the branch predictors
optimizing for the non-fail path.
Some notes on the bounds checker:
- it does not instrument {mem,str}*()-family functions, it only
instruments direct indexed accesses (e.g. "foo[i]"). Dealing with
the {mem,str}*()-family functions is a work-in-progress around
CONFIG_FORTIFY_SOURCE[1].
- it ignores flexible array members, including the very old single
byte (e.g. "int foo[1];") declarations. (Note that GCC's
implementation appears to ignore _all_ trailing arrays, but Clang only
ignores empty, 0, and 1 byte arrays[2].)
[1] https://github.com/KSPP/linux/issues/6
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589
Suggested-by: Elena Petrova <lenaptr@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Acked-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Link: http://lkml.kernel.org/r/20200227193516.32566-3-keescook@chromium.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-04-06 20:12:31 -07:00
|
|
|
menuconfig UBSAN
|
2016-01-20 16:00:55 -07:00
|
|
|
bool "Undefined behaviour sanity checker"
|
2024-05-14 16:37:48 -07:00
|
|
|
depends on ARCH_HAS_UBSAN
|
2016-01-20 16:00:55 -07:00
|
|
|
help
|
2020-04-06 20:12:27 -07:00
|
|
|
This option enables the Undefined Behaviour sanity checker.
|
2016-01-20 16:00:55 -07:00
|
|
|
Compile-time instrumentation is used to detect various undefined
|
2020-04-06 20:12:27 -07:00
|
|
|
behaviours at runtime. For more details, see:
|
|
|
|
|
Documentation/dev-tools/ubsan.rst
|
|
|
|
|
|
ubsan: split "bounds" checker from other options
In order to do kernel builds with the bounds checker individually
available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under
CONFIG_UBSAN_MISC.
For example, using this, we can start to expand the coverage syzkaller is
providing. Right now, all of UBSan is disabled for syzbot builds because
taken as a whole, it is too noisy. This will let us focus on one feature
at a time.
For the bounds checker specifically, this provides a mechanism to
eliminate an entire class of array overflows with close to zero
performance overhead (I cannot measure a difference). In my (mostly)
defconfig, enabling bounds checking adds ~4200 checks to the kernel.
Performance changes are in the noise, likely due to the branch predictors
optimizing for the non-fail path.
Some notes on the bounds checker:
- it does not instrument {mem,str}*()-family functions, it only
instruments direct indexed accesses (e.g. "foo[i]"). Dealing with
the {mem,str}*()-family functions is a work-in-progress around
CONFIG_FORTIFY_SOURCE[1].
- it ignores flexible array members, including the very old single
byte (e.g. "int foo[1];") declarations. (Note that GCC's
implementation appears to ignore _all_ trailing arrays, but Clang only
ignores empty, 0, and 1 byte arrays[2].)
[1] https://github.com/KSPP/linux/issues/6
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589
Suggested-by: Elena Petrova <lenaptr@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Acked-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Link: http://lkml.kernel.org/r/20200227193516.32566-3-keescook@chromium.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-04-06 20:12:31 -07:00
|
|
|
if UBSAN
|
|
|
|
|
|
2020-04-06 20:12:27 -07:00
|
|
|
config UBSAN_TRAP
|
2023-07-05 14:51:27 -07:00
|
|
|
bool "Abort on Sanitizer warnings (smaller kernel but less verbose)"
|
2020-12-15 21:46:31 -07:00
|
|
|
depends on !COMPILE_TEST
|
2020-04-06 20:12:27 -07:00
|
|
|
help
|
|
|
|
|
Building kernels with Sanitizer features enabled tends to grow
|
|
|
|
|
the kernel size by around 5%, due to adding all the debugging
|
|
|
|
|
text on failure paths. To avoid this, Sanitizer instrumentation
|
|
|
|
|
can just issue a trap. This reduces the kernel size overhead but
|
|
|
|
|
turns all warnings (including potentially harmless conditions)
|
|
|
|
|
into full exceptions that abort the running kernel code
|
|
|
|
|
(regardless of context, locks held, etc), which may destabilize
|
|
|
|
|
the system. For some system builders this is an acceptable
|
|
|
|
|
trade-off.
|
2016-01-20 16:00:55 -07:00
|
|
|
|
2023-07-05 14:51:27 -07:00
|
|
|
Also note that selecting Y will cause your kernel to Oops
|
|
|
|
|
with an "illegal instruction" error with no further details
|
2024-07-23 17:01:55 -07:00
|
|
|
when a UBSAN violation occurs. (Except on arm64 and x86, which
|
|
|
|
|
will report which Sanitizer failed.) This may make it hard to
|
2023-07-05 14:51:27 -07:00
|
|
|
determine whether an Oops was caused by UBSAN or to figure
|
|
|
|
|
out the details of a UBSAN violation. It makes the kernel log
|
|
|
|
|
output less useful for bug reports.
|
|
|
|
|
|
2023-04-04 19:23:59 -07:00
|
|
|
config CC_HAS_UBSAN_BOUNDS_STRICT
|
|
|
|
|
def_bool $(cc-option,-fsanitize=bounds-strict)
|
|
|
|
|
help
|
|
|
|
|
The -fsanitize=bounds-strict option is only available on GCC,
|
|
|
|
|
but uses the more strict handling of arrays that includes knowledge
|
|
|
|
|
of flexible arrays, which is comparable to Clang's regular
|
|
|
|
|
-fsanitize=bounds.
|
2020-12-15 21:46:24 -07:00
|
|
|
|
|
|
|
|
config CC_HAS_UBSAN_ARRAY_BOUNDS
|
|
|
|
|
def_bool $(cc-option,-fsanitize=array-bounds)
|
2023-04-04 19:23:59 -07:00
|
|
|
help
|
|
|
|
|
Under Clang, the -fsanitize=bounds option is actually composed
|
|
|
|
|
of two more specific options, -fsanitize=array-bounds and
|
|
|
|
|
-fsanitize=local-bounds. However, -fsanitize=local-bounds can
|
|
|
|
|
only be used when trap mode is enabled. (See also the help for
|
|
|
|
|
CONFIG_LOCAL_BOUNDS.) Explicitly check for -fsanitize=array-bounds
|
|
|
|
|
so that we can build up the options needed for UBSAN_BOUNDS
|
|
|
|
|
with or without UBSAN_TRAP.
|
2020-12-15 21:46:24 -07:00
|
|
|
|
ubsan: split "bounds" checker from other options
In order to do kernel builds with the bounds checker individually
available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under
CONFIG_UBSAN_MISC.
For example, using this, we can start to expand the coverage syzkaller is
providing. Right now, all of UBSan is disabled for syzbot builds because
taken as a whole, it is too noisy. This will let us focus on one feature
at a time.
For the bounds checker specifically, this provides a mechanism to
eliminate an entire class of array overflows with close to zero
performance overhead (I cannot measure a difference). In my (mostly)
defconfig, enabling bounds checking adds ~4200 checks to the kernel.
Performance changes are in the noise, likely due to the branch predictors
optimizing for the non-fail path.
Some notes on the bounds checker:
- it does not instrument {mem,str}*()-family functions, it only
instruments direct indexed accesses (e.g. "foo[i]"). Dealing with
the {mem,str}*()-family functions is a work-in-progress around
CONFIG_FORTIFY_SOURCE[1].
- it ignores flexible array members, including the very old single
byte (e.g. "int foo[1];") declarations. (Note that GCC's
implementation appears to ignore _all_ trailing arrays, but Clang only
ignores empty, 0, and 1 byte arrays[2].)
[1] https://github.com/KSPP/linux/issues/6
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589
Suggested-by: Elena Petrova <lenaptr@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Acked-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Link: http://lkml.kernel.org/r/20200227193516.32566-3-keescook@chromium.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-04-06 20:12:31 -07:00
|
|
|
config UBSAN_BOUNDS
|
|
|
|
|
bool "Perform array index bounds checking"
|
|
|
|
|
default UBSAN
|
2023-04-04 19:23:59 -07:00
|
|
|
depends on CC_HAS_UBSAN_ARRAY_BOUNDS || CC_HAS_UBSAN_BOUNDS_STRICT
|
ubsan: split "bounds" checker from other options
In order to do kernel builds with the bounds checker individually
available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under
CONFIG_UBSAN_MISC.
For example, using this, we can start to expand the coverage syzkaller is
providing. Right now, all of UBSan is disabled for syzbot builds because
taken as a whole, it is too noisy. This will let us focus on one feature
at a time.
For the bounds checker specifically, this provides a mechanism to
eliminate an entire class of array overflows with close to zero
performance overhead (I cannot measure a difference). In my (mostly)
defconfig, enabling bounds checking adds ~4200 checks to the kernel.
Performance changes are in the noise, likely due to the branch predictors
optimizing for the non-fail path.
Some notes on the bounds checker:
- it does not instrument {mem,str}*()-family functions, it only
instruments direct indexed accesses (e.g. "foo[i]"). Dealing with
the {mem,str}*()-family functions is a work-in-progress around
CONFIG_FORTIFY_SOURCE[1].
- it ignores flexible array members, including the very old single
byte (e.g. "int foo[1];") declarations. (Note that GCC's
implementation appears to ignore _all_ trailing arrays, but Clang only
ignores empty, 0, and 1 byte arrays[2].)
[1] https://github.com/KSPP/linux/issues/6
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589
Suggested-by: Elena Petrova <lenaptr@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Acked-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Link: http://lkml.kernel.org/r/20200227193516.32566-3-keescook@chromium.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-04-06 20:12:31 -07:00
|
|
|
help
|
|
|
|
|
This option enables detection of directly indexed out of bounds
|
|
|
|
|
array accesses, where the array size is known at compile time.
|
|
|
|
|
Note that this does not protect array overflows via bad calls
|
|
|
|
|
to the {str,mem}*cpy() family of functions (that is addressed
|
|
|
|
|
by CONFIG_FORTIFY_SOURCE).
|
|
|
|
|
|
2023-04-04 19:23:59 -07:00
|
|
|
config UBSAN_BOUNDS_STRICT
|
|
|
|
|
def_bool UBSAN_BOUNDS && CC_HAS_UBSAN_BOUNDS_STRICT
|
2020-12-15 21:46:24 -07:00
|
|
|
help
|
2023-04-04 19:23:59 -07:00
|
|
|
GCC's bounds sanitizer. This option is used to select the
|
|
|
|
|
correct options in Makefile.ubsan.
|
2020-12-15 21:46:24 -07:00
|
|
|
|
|
|
|
|
config UBSAN_ARRAY_BOUNDS
|
2023-04-04 19:23:59 -07:00
|
|
|
def_bool UBSAN_BOUNDS && CC_HAS_UBSAN_ARRAY_BOUNDS
|
|
|
|
|
help
|
|
|
|
|
Clang's array bounds sanitizer. This option is used to select
|
|
|
|
|
the correct options in Makefile.ubsan.
|
2020-12-15 21:46:24 -07:00
|
|
|
|
2020-10-15 20:13:38 -07:00
|
|
|
config UBSAN_LOCAL_BOUNDS
|
2023-04-04 19:23:59 -07:00
|
|
|
def_bool UBSAN_ARRAY_BOUNDS && UBSAN_TRAP
|
2020-10-15 20:13:38 -07:00
|
|
|
help
|
2023-04-04 19:23:59 -07:00
|
|
|
This option enables Clang's -fsanitize=local-bounds which traps
|
|
|
|
|
when an access through a pointer that is derived from an object
|
|
|
|
|
of a statically-known size, where an added offset (which may not
|
|
|
|
|
be known statically) is out-of-bounds. Since this option is
|
|
|
|
|
trap-only, it depends on CONFIG_UBSAN_TRAP.
|
2020-10-15 20:13:38 -07:00
|
|
|
|
2020-12-15 21:46:24 -07:00
|
|
|
config UBSAN_SHIFT
|
2020-12-15 21:46:39 -07:00
|
|
|
bool "Perform checking for bit-shift overflows"
|
2020-12-15 21:46:24 -07:00
|
|
|
depends on $(cc-option,-fsanitize=shift)
|
2020-12-15 21:46:39 -07:00
|
|
|
help
|
|
|
|
|
This option enables -fsanitize=shift which checks for bit-shift
|
|
|
|
|
operations that overflow to the left or go switch to negative
|
|
|
|
|
for signed types.
|
2020-12-15 21:46:24 -07:00
|
|
|
|
|
|
|
|
config UBSAN_DIV_ZERO
|
2020-12-15 21:46:39 -07:00
|
|
|
bool "Perform checking for integer divide-by-zero"
|
2020-12-15 21:46:24 -07:00
|
|
|
depends on $(cc-option,-fsanitize=integer-divide-by-zero)
|
2022-07-14 13:56:43 -07:00
|
|
|
# https://github.com/ClangBuiltLinux/linux/issues/1657
|
|
|
|
|
# https://github.com/llvm/llvm-project/issues/56289
|
|
|
|
|
depends on !CC_IS_CLANG
|
2020-12-15 21:46:39 -07:00
|
|
|
help
|
|
|
|
|
This option enables -fsanitize=integer-divide-by-zero which checks
|
|
|
|
|
for integer division by zero. This is effectively redundant with the
|
|
|
|
|
kernel's existing exception handling, though it can provide greater
|
|
|
|
|
debugging information under CONFIG_UBSAN_REPORT_FULL.
|
2020-12-15 21:46:24 -07:00
|
|
|
|
|
|
|
|
config UBSAN_UNREACHABLE
|
2020-12-15 21:46:39 -07:00
|
|
|
bool "Perform checking for unreachable code"
|
|
|
|
|
# objtool already handles unreachable checking and gets angry about
|
|
|
|
|
# seeing UBSan instrumentation located in unreachable places.
|
2022-06-01 09:42:12 -07:00
|
|
|
depends on !(OBJTOOL && (STACK_VALIDATION || UNWINDER_ORC || HAVE_UACCESS_VALIDATION))
|
2020-12-15 21:46:24 -07:00
|
|
|
depends on $(cc-option,-fsanitize=unreachable)
|
2020-12-15 21:46:39 -07:00
|
|
|
help
|
|
|
|
|
This option enables -fsanitize=unreachable which checks for control
|
|
|
|
|
flow reaching an expected-to-be-unreachable position.
|
2020-12-15 21:46:24 -07:00
|
|
|
|
2024-01-18 16:06:05 -07:00
|
|
|
config UBSAN_SIGNED_WRAP
|
|
|
|
|
bool "Perform checking for signed arithmetic wrap-around"
|
|
|
|
|
default UBSAN
|
|
|
|
|
depends on !COMPILE_TEST
|
2024-03-12 20:45:52 -07:00
|
|
|
# The no_sanitize attribute was introduced in GCC with version 8.
|
|
|
|
|
depends on !CC_IS_GCC || GCC_VERSION >= 80000
|
2024-01-18 16:06:05 -07:00
|
|
|
depends on $(cc-option,-fsanitize=signed-integer-overflow)
|
|
|
|
|
help
|
|
|
|
|
This option enables -fsanitize=signed-integer-overflow which checks
|
|
|
|
|
for wrap-around of any arithmetic operations with signed integers.
|
|
|
|
|
This currently performs nearly no instrumentation due to the
|
|
|
|
|
kernel's use of -fno-strict-overflow which converts all would-be
|
|
|
|
|
arithmetic undefined behavior into wrap-around arithmetic. Future
|
|
|
|
|
sanitizer versions will allow for wrap-around checking (rather than
|
|
|
|
|
exclusively undefined behavior).
|
|
|
|
|
|
2020-12-15 21:46:24 -07:00
|
|
|
config UBSAN_BOOL
|
2020-12-15 21:46:39 -07:00
|
|
|
bool "Perform checking for non-boolean values used as boolean"
|
|
|
|
|
default UBSAN
|
2020-12-15 21:46:24 -07:00
|
|
|
depends on $(cc-option,-fsanitize=bool)
|
2020-12-15 21:46:39 -07:00
|
|
|
help
|
|
|
|
|
This option enables -fsanitize=bool which checks for boolean values being
|
|
|
|
|
loaded that are neither 0 nor 1.
|
2020-12-15 21:46:24 -07:00
|
|
|
|
|
|
|
|
config UBSAN_ENUM
|
2020-12-15 21:46:39 -07:00
|
|
|
bool "Perform checking for out of bounds enum values"
|
|
|
|
|
default UBSAN
|
2020-12-15 21:46:24 -07:00
|
|
|
depends on $(cc-option,-fsanitize=enum)
|
2020-12-15 21:46:39 -07:00
|
|
|
help
|
|
|
|
|
This option enables -fsanitize=enum which checks for values being loaded
|
|
|
|
|
into an enum that are outside the range of given values for the given enum.
|
|
|
|
|
|
|
|
|
|
config UBSAN_ALIGNMENT
|
|
|
|
|
bool "Perform checking for misaligned pointer usage"
|
|
|
|
|
default !HAVE_EFFICIENT_UNALIGNED_ACCESS
|
|
|
|
|
depends on !UBSAN_TRAP && !COMPILE_TEST
|
|
|
|
|
depends on $(cc-option,-fsanitize=alignment)
|
|
|
|
|
help
|
|
|
|
|
This option enables the check of unaligned memory accesses.
|
|
|
|
|
Enabling this option on architectures that support unaligned
|
|
|
|
|
accesses may produce a lot of false positives.
|
2020-12-15 21:46:24 -07:00
|
|
|
|
2018-04-10 16:32:58 -07:00
|
|
|
config TEST_UBSAN
|
|
|
|
|
tristate "Module for testing for undefined behavior detection"
|
ubsan: split "bounds" checker from other options
In order to do kernel builds with the bounds checker individually
available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under
CONFIG_UBSAN_MISC.
For example, using this, we can start to expand the coverage syzkaller is
providing. Right now, all of UBSan is disabled for syzbot builds because
taken as a whole, it is too noisy. This will let us focus on one feature
at a time.
For the bounds checker specifically, this provides a mechanism to
eliminate an entire class of array overflows with close to zero
performance overhead (I cannot measure a difference). In my (mostly)
defconfig, enabling bounds checking adds ~4200 checks to the kernel.
Performance changes are in the noise, likely due to the branch predictors
optimizing for the non-fail path.
Some notes on the bounds checker:
- it does not instrument {mem,str}*()-family functions, it only
instruments direct indexed accesses (e.g. "foo[i]"). Dealing with
the {mem,str}*()-family functions is a work-in-progress around
CONFIG_FORTIFY_SOURCE[1].
- it ignores flexible array members, including the very old single
byte (e.g. "int foo[1];") declarations. (Note that GCC's
implementation appears to ignore _all_ trailing arrays, but Clang only
ignores empty, 0, and 1 byte arrays[2].)
[1] https://github.com/KSPP/linux/issues/6
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589
Suggested-by: Elena Petrova <lenaptr@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Acked-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Link: http://lkml.kernel.org/r/20200227193516.32566-3-keescook@chromium.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-04-06 20:12:31 -07:00
|
|
|
depends on m
|
2018-04-10 16:32:58 -07:00
|
|
|
help
|
|
|
|
|
This is a test module for UBSAN.
|
|
|
|
|
It triggers various undefined behavior, and detect it.
|
ubsan: split "bounds" checker from other options
In order to do kernel builds with the bounds checker individually
available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under
CONFIG_UBSAN_MISC.
For example, using this, we can start to expand the coverage syzkaller is
providing. Right now, all of UBSan is disabled for syzbot builds because
taken as a whole, it is too noisy. This will let us focus on one feature
at a time.
For the bounds checker specifically, this provides a mechanism to
eliminate an entire class of array overflows with close to zero
performance overhead (I cannot measure a difference). In my (mostly)
defconfig, enabling bounds checking adds ~4200 checks to the kernel.
Performance changes are in the noise, likely due to the branch predictors
optimizing for the non-fail path.
Some notes on the bounds checker:
- it does not instrument {mem,str}*()-family functions, it only
instruments direct indexed accesses (e.g. "foo[i]"). Dealing with
the {mem,str}*()-family functions is a work-in-progress around
CONFIG_FORTIFY_SOURCE[1].
- it ignores flexible array members, including the very old single
byte (e.g. "int foo[1];") declarations. (Note that GCC's
implementation appears to ignore _all_ trailing arrays, but Clang only
ignores empty, 0, and 1 byte arrays[2].)
[1] https://github.com/KSPP/linux/issues/6
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589
Suggested-by: Elena Petrova <lenaptr@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Acked-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Link: http://lkml.kernel.org/r/20200227193516.32566-3-keescook@chromium.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-04-06 20:12:31 -07:00
|
|
|
|
|
|
|
|
endif # if UBSAN
|