2019-05-19 20:07:45 +08:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
2016-01-21 07:00:55 +08:00
|
|
|
config ARCH_HAS_UBSAN_SANITIZE_ALL
|
|
|
|
|
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-07 11:12:31 +08:00
|
|
|
menuconfig UBSAN
|
2016-01-21 07:00:55 +08:00
|
|
|
bool "Undefined behaviour sanity checker"
|
|
|
|
|
help
|
2020-04-07 11:12:27 +08:00
|
|
|
This option enables the Undefined Behaviour sanity checker.
|
2016-01-21 07:00:55 +08:00
|
|
|
Compile-time instrumentation is used to detect various undefined
|
2020-04-07 11:12:27 +08: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-07 11:12:31 +08:00
|
|
|
if UBSAN
|
|
|
|
|
|
2020-04-07 11:12:27 +08:00
|
|
|
config UBSAN_TRAP
|
|
|
|
|
bool "On Sanitizer warnings, abort the running kernel code"
|
2020-12-16 12:46:31 +08:00
|
|
|
depends on !COMPILE_TEST
|
2020-04-07 11:12:27 +08:00
|
|
|
depends on $(cc-option, -fsanitize-undefined-trap-on-error)
|
|
|
|
|
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-21 07:00:55 +08:00
|
|
|
|
2020-05-21 22:20:37 +08:00
|
|
|
config UBSAN_KCOV_BROKEN
|
|
|
|
|
def_bool KCOV && CC_HAS_SANCOV_TRACE_PC
|
|
|
|
|
depends on CC_IS_CLANG
|
|
|
|
|
depends on !$(cc-option,-Werror=unused-command-line-argument -fsanitize=bounds -fsanitize-coverage=trace-pc)
|
|
|
|
|
help
|
|
|
|
|
Some versions of clang support either UBSAN or KCOV but not the
|
|
|
|
|
combination of the two.
|
|
|
|
|
See https://bugs.llvm.org/show_bug.cgi?id=45831 for the status
|
|
|
|
|
in newer releases.
|
|
|
|
|
|
2020-12-16 12:46:24 +08:00
|
|
|
config CC_HAS_UBSAN_BOUNDS
|
|
|
|
|
def_bool $(cc-option,-fsanitize=bounds)
|
|
|
|
|
|
|
|
|
|
config CC_HAS_UBSAN_ARRAY_BOUNDS
|
|
|
|
|
def_bool $(cc-option,-fsanitize=array-bounds)
|
|
|
|
|
|
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-07 11:12:31 +08:00
|
|
|
config UBSAN_BOUNDS
|
|
|
|
|
bool "Perform array index bounds checking"
|
|
|
|
|
default UBSAN
|
2020-05-21 22:20:37 +08:00
|
|
|
depends on !UBSAN_KCOV_BROKEN
|
2020-12-16 12:46:24 +08:00
|
|
|
depends on CC_HAS_UBSAN_ARRAY_BOUNDS || CC_HAS_UBSAN_BOUNDS
|
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-07 11:12:31 +08: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).
|
|
|
|
|
|
2020-12-16 12:46:24 +08:00
|
|
|
config UBSAN_ONLY_BOUNDS
|
|
|
|
|
def_bool CC_HAS_UBSAN_BOUNDS && !CC_HAS_UBSAN_ARRAY_BOUNDS
|
|
|
|
|
depends on UBSAN_BOUNDS
|
|
|
|
|
help
|
|
|
|
|
This is a weird case: Clang's -fsanitize=bounds includes
|
|
|
|
|
-fsanitize=local-bounds, but it's trapping-only, so for
|
|
|
|
|
Clang, we must use -fsanitize=array-bounds when we want
|
|
|
|
|
traditional array bounds checking enabled. For GCC, we
|
|
|
|
|
want -fsanitize=bounds.
|
|
|
|
|
|
|
|
|
|
config UBSAN_ARRAY_BOUNDS
|
|
|
|
|
def_bool CC_HAS_UBSAN_ARRAY_BOUNDS
|
|
|
|
|
depends on UBSAN_BOUNDS
|
|
|
|
|
|
2020-10-16 11:13:38 +08:00
|
|
|
config UBSAN_LOCAL_BOUNDS
|
|
|
|
|
bool "Perform array local bounds checking"
|
|
|
|
|
depends on UBSAN_TRAP
|
|
|
|
|
depends on !UBSAN_KCOV_BROKEN
|
2020-12-16 12:46:24 +08:00
|
|
|
depends on $(cc-option,-fsanitize=local-bounds)
|
2020-10-16 11:13:38 +08:00
|
|
|
help
|
|
|
|
|
This option enables -fsanitize=local-bounds which traps when an
|
2020-12-16 12:46:24 +08:00
|
|
|
exception/error is detected. Therefore, it may only be enabled
|
|
|
|
|
with CONFIG_UBSAN_TRAP.
|
|
|
|
|
|
2020-10-16 11:13:38 +08:00
|
|
|
Enabling this option detects errors due to accesses 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.
|
|
|
|
|
|
2020-12-16 12:46:24 +08:00
|
|
|
config UBSAN_SHIFT
|
2020-12-16 12:46:39 +08:00
|
|
|
bool "Perform checking for bit-shift overflows"
|
|
|
|
|
default UBSAN
|
2020-12-16 12:46:24 +08:00
|
|
|
depends on $(cc-option,-fsanitize=shift)
|
2020-12-16 12:46:39 +08: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-16 12:46:24 +08:00
|
|
|
|
|
|
|
|
config UBSAN_DIV_ZERO
|
2020-12-16 12:46:39 +08:00
|
|
|
bool "Perform checking for integer divide-by-zero"
|
2020-12-16 12:46:24 +08:00
|
|
|
depends on $(cc-option,-fsanitize=integer-divide-by-zero)
|
2020-12-16 12:46:39 +08: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-16 12:46:24 +08:00
|
|
|
|
|
|
|
|
config UBSAN_UNREACHABLE
|
2020-12-16 12:46:39 +08:00
|
|
|
bool "Perform checking for unreachable code"
|
|
|
|
|
# objtool already handles unreachable checking and gets angry about
|
|
|
|
|
# seeing UBSan instrumentation located in unreachable places.
|
|
|
|
|
depends on !STACK_VALIDATION
|
2020-12-16 12:46:24 +08:00
|
|
|
depends on $(cc-option,-fsanitize=unreachable)
|
2020-12-16 12:46:39 +08:00
|
|
|
help
|
|
|
|
|
This option enables -fsanitize=unreachable which checks for control
|
|
|
|
|
flow reaching an expected-to-be-unreachable position.
|
2020-12-16 12:46:24 +08:00
|
|
|
|
|
|
|
|
config UBSAN_OBJECT_SIZE
|
2020-12-16 12:46:39 +08:00
|
|
|
bool "Perform checking for accesses beyond the end of objects"
|
|
|
|
|
default UBSAN
|
2020-12-16 12:46:28 +08:00
|
|
|
# gcc hugely expands stack usage with -fsanitize=object-size
|
|
|
|
|
# https://lore.kernel.org/lkml/CAHk-=wjPasyJrDuwDnpHJS2TuQfExwe=px-SzLeN8GFMAQJPmQ@mail.gmail.com/
|
|
|
|
|
depends on !CC_IS_GCC
|
2020-12-16 12:46:24 +08:00
|
|
|
depends on $(cc-option,-fsanitize=object-size)
|
2020-12-16 12:46:39 +08:00
|
|
|
help
|
|
|
|
|
This option enables -fsanitize=object-size which checks for accesses
|
|
|
|
|
beyond the end of objects where the optimizer can determine both the
|
|
|
|
|
object being operated on and its size, usually seen with bad downcasts,
|
|
|
|
|
or access to struct members from NULL pointers.
|
2020-12-16 12:46:24 +08:00
|
|
|
|
|
|
|
|
config UBSAN_BOOL
|
2020-12-16 12:46:39 +08:00
|
|
|
bool "Perform checking for non-boolean values used as boolean"
|
|
|
|
|
default UBSAN
|
2020-12-16 12:46:24 +08:00
|
|
|
depends on $(cc-option,-fsanitize=bool)
|
2020-12-16 12:46:39 +08:00
|
|
|
help
|
|
|
|
|
This option enables -fsanitize=bool which checks for boolean values being
|
|
|
|
|
loaded that are neither 0 nor 1.
|
2020-12-16 12:46:24 +08:00
|
|
|
|
|
|
|
|
config UBSAN_ENUM
|
2020-12-16 12:46:39 +08:00
|
|
|
bool "Perform checking for out of bounds enum values"
|
|
|
|
|
default UBSAN
|
2020-12-16 12:46:24 +08:00
|
|
|
depends on $(cc-option,-fsanitize=enum)
|
2020-12-16 12:46:39 +08: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-16 12:46:24 +08:00
|
|
|
|
2016-01-21 07:00:55 +08:00
|
|
|
config UBSAN_SANITIZE_ALL
|
|
|
|
|
bool "Enable instrumentation for the entire kernel"
|
|
|
|
|
depends on ARCH_HAS_UBSAN_SANITIZE_ALL
|
|
|
|
|
default y
|
|
|
|
|
help
|
|
|
|
|
This option activates instrumentation for the entire kernel.
|
|
|
|
|
If you don't enable this option, you have to explicitly specify
|
|
|
|
|
UBSAN_SANITIZE := y for the files/directories you want to check for UB.
|
2016-02-12 08:12:55 +08:00
|
|
|
Enabling this option will get kernel image size increased
|
|
|
|
|
significantly.
|
2016-01-21 07:00:55 +08:00
|
|
|
|
2018-04-11 07:32:58 +08: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-07 11:12:31 +08:00
|
|
|
depends on m
|
2018-04-11 07:32:58 +08: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-07 11:12:31 +08:00
|
|
|
|
|
|
|
|
endif # if UBSAN
|