* [PATCH v3 1/6] ubsan: Add trap instrumentation option
2020-01-16 1:23 [PATCH v3 0/6] ubsan: Split out bounds checker Kees Cook
@ 2020-01-16 1:23 ` Kees Cook
2020-01-16 1:23 ` [PATCH v3 2/6] ubsan: Split "bounds" checker from other options Kees Cook
` (4 subsequent siblings)
5 siblings, 0 replies; 13+ messages in thread
From: Kees Cook @ 2020-01-16 1:23 UTC (permalink / raw)
To: Andrew Morton
Cc: Kees Cook, Elena Petrova, Dmitry Vyukov, Andrey Ryabinin,
Alexander Potapenko, Dan Carpenter, Gustavo A. R. Silva,
Arnd Bergmann, Ard Biesheuvel, kasan-dev, linux-mm, linux-kernel,
kernel-hardening, syzkaller
The Undefined Behavior Sanitizer can operate in two modes: warning
reporting mode via lib/ubsan.c handler calls, or trap mode, which uses
__builtin_trap() as the handler. Using lib/ubsan.c means the kernel
image is about 5% larger (due to all the debugging text and reporting
structures to capture details about the warning conditions). Using the
trap mode, the image size changes are much smaller, though at the loss
of the "warning only" mode.
In order to give greater flexibility to system builders that want
minimal changes to image size and are prepared to deal with kernel code
being aborted and potentially destabilizing the system, this introduces
CONFIG_UBSAN_TRAP. The resulting image sizes comparison:
text data bss dec hex filename
19533663 6183037 18554956 44271656 2a38828 vmlinux.stock
19991849 7618513 18874448 46484810 2c54d4a vmlinux.ubsan
19712181 6284181 18366540 44362902 2a4ec96 vmlinux.ubsan-trap
CONFIG_UBSAN=y: image +4.8% (text +2.3%, data +18.9%)
CONFIG_UBSAN_TRAP=y: image +0.2% (text +0.9%, data +1.6%)
Additionally adjusts the CONFIG_UBSAN Kconfig help for clarity and
removes the mention of non-existing boot param "ubsan_handle".
Suggested-by: Elena Petrova <lenaptr@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Dmitry Vyukov <dvyukov@google.com>
---
lib/Kconfig.ubsan | 22 ++++++++++++++++++----
lib/Makefile | 2 ++
scripts/Makefile.ubsan | 9 +++++++--
3 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
index 0e04fcb3ab3d..9deb655838b0 100644
--- a/lib/Kconfig.ubsan
+++ b/lib/Kconfig.ubsan
@@ -5,11 +5,25 @@ config ARCH_HAS_UBSAN_SANITIZE_ALL
config UBSAN
bool "Undefined behaviour sanity checker"
help
- This option enables undefined behaviour sanity checker
+ This option enables the Undefined Behaviour sanity checker.
Compile-time instrumentation is used to detect various undefined
- behaviours in runtime. Various types of checks may be enabled
- via boot parameter ubsan_handle
- (see: Documentation/dev-tools/ubsan.rst).
+ behaviours at runtime. For more details, see:
+ Documentation/dev-tools/ubsan.rst
+
+config UBSAN_TRAP
+ bool "On Sanitizer warnings, abort the running kernel code"
+ depends on UBSAN
+ 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.
config UBSAN_SANITIZE_ALL
bool "Enable instrumentation for the entire kernel"
diff --git a/lib/Makefile b/lib/Makefile
index 93217d44237f..3114ef1727f8 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -275,7 +275,9 @@ quiet_cmd_build_OID_registry = GEN $@
clean-files += oid_registry_data.c
obj-$(CONFIG_UCS2_STRING) += ucs2_string.o
+ifneq ($(CONFIG_UBSAN_TRAP),y)
obj-$(CONFIG_UBSAN) += ubsan.o
+endif
UBSAN_SANITIZE_ubsan.o := n
KASAN_SANITIZE_ubsan.o := n
diff --git a/scripts/Makefile.ubsan b/scripts/Makefile.ubsan
index 019771b845c5..668a91510bfe 100644
--- a/scripts/Makefile.ubsan
+++ b/scripts/Makefile.ubsan
@@ -1,5 +1,10 @@
# SPDX-License-Identifier: GPL-2.0
ifdef CONFIG_UBSAN
+
+ifdef CONFIG_UBSAN_ALIGNMENT
+ CFLAGS_UBSAN += $(call cc-option, -fsanitize=alignment)
+endif
+
CFLAGS_UBSAN += $(call cc-option, -fsanitize=shift)
CFLAGS_UBSAN += $(call cc-option, -fsanitize=integer-divide-by-zero)
CFLAGS_UBSAN += $(call cc-option, -fsanitize=unreachable)
@@ -9,8 +14,8 @@ ifdef CONFIG_UBSAN
CFLAGS_UBSAN += $(call cc-option, -fsanitize=bool)
CFLAGS_UBSAN += $(call cc-option, -fsanitize=enum)
-ifdef CONFIG_UBSAN_ALIGNMENT
- CFLAGS_UBSAN += $(call cc-option, -fsanitize=alignment)
+ifdef CONFIG_UBSAN_TRAP
+ CFLAGS_UBSAN += $(call cc-option, -fsanitize-undefined-trap-on-error)
endif
# -fsanitize=* options makes GCC less smart than usual and
--
2.20.1
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v3 2/6] ubsan: Split "bounds" checker from other options
2020-01-16 1:23 [PATCH v3 0/6] ubsan: Split out bounds checker Kees Cook
2020-01-16 1:23 ` [PATCH v3 1/6] ubsan: Add trap instrumentation option Kees Cook
@ 2020-01-16 1:23 ` Kees Cook
2020-01-16 1:23 ` [PATCH v3 3/6] lkdtm/bugs: Add arithmetic overflow and array bounds checks Kees Cook
` (3 subsequent siblings)
5 siblings, 0 replies; 13+ messages in thread
From: Kees Cook @ 2020-01-16 1:23 UTC (permalink / raw)
To: Andrew Morton
Cc: Kees Cook, Elena Petrova, Andrey Ryabinin, Dmitry Vyukov,
Alexander Potapenko, Dan Carpenter, Gustavo A. R. Silva,
Arnd Bergmann, Ard Biesheuvel, kasan-dev, linux-mm, linux-kernel,
kernel-hardening, syzkaller
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>
Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Acked-by: Dmitry Vyukov <dvyukov@google.com>
---
lib/Kconfig.ubsan | 29 ++++++++++++++++++++++++-----
scripts/Makefile.ubsan | 7 ++++++-
2 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
index 9deb655838b0..48469c95d78e 100644
--- a/lib/Kconfig.ubsan
+++ b/lib/Kconfig.ubsan
@@ -2,7 +2,7 @@
config ARCH_HAS_UBSAN_SANITIZE_ALL
bool
-config UBSAN
+menuconfig UBSAN
bool "Undefined behaviour sanity checker"
help
This option enables the Undefined Behaviour sanity checker.
@@ -10,9 +10,10 @@ config UBSAN
behaviours at runtime. For more details, see:
Documentation/dev-tools/ubsan.rst
+if UBSAN
+
config UBSAN_TRAP
bool "On Sanitizer warnings, abort the running kernel code"
- depends on UBSAN
depends on $(cc-option, -fsanitize-undefined-trap-on-error)
help
Building kernels with Sanitizer features enabled tends to grow
@@ -25,9 +26,26 @@ config UBSAN_TRAP
the system. For some system builders this is an acceptable
trade-off.
+config UBSAN_BOUNDS
+ bool "Perform array index bounds checking"
+ default UBSAN
+ 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).
+
+config UBSAN_MISC
+ bool "Enable all other Undefined Behavior sanity checks"
+ default UBSAN
+ help
+ This option enables all sanity checks that don't have their
+ own Kconfig options. Disable this if you only want to have
+ individually selected checks.
+
config UBSAN_SANITIZE_ALL
bool "Enable instrumentation for the entire kernel"
- depends on UBSAN
depends on ARCH_HAS_UBSAN_SANITIZE_ALL
# We build with -Wno-maybe-uninitilzed, but we still want to
@@ -44,7 +62,6 @@ config UBSAN_SANITIZE_ALL
config UBSAN_NO_ALIGNMENT
bool "Disable checking of pointers alignment"
- depends on UBSAN
default y if HAVE_EFFICIENT_UNALIGNED_ACCESS
help
This option disables the check of unaligned memory accesses.
@@ -57,7 +74,9 @@ config UBSAN_ALIGNMENT
config TEST_UBSAN
tristate "Module for testing for undefined behavior detection"
- depends on m && UBSAN
+ depends on m
help
This is a test module for UBSAN.
It triggers various undefined behavior, and detect it.
+
+endif # if UBSAN
diff --git a/scripts/Makefile.ubsan b/scripts/Makefile.ubsan
index 668a91510bfe..5b15bc425ec9 100644
--- a/scripts/Makefile.ubsan
+++ b/scripts/Makefile.ubsan
@@ -5,14 +5,19 @@ ifdef CONFIG_UBSAN_ALIGNMENT
CFLAGS_UBSAN += $(call cc-option, -fsanitize=alignment)
endif
+ifdef CONFIG_UBSAN_BOUNDS
+ CFLAGS_UBSAN += $(call cc-option, -fsanitize=bounds)
+endif
+
+ifdef CONFIG_UBSAN_MISC
CFLAGS_UBSAN += $(call cc-option, -fsanitize=shift)
CFLAGS_UBSAN += $(call cc-option, -fsanitize=integer-divide-by-zero)
CFLAGS_UBSAN += $(call cc-option, -fsanitize=unreachable)
CFLAGS_UBSAN += $(call cc-option, -fsanitize=signed-integer-overflow)
- CFLAGS_UBSAN += $(call cc-option, -fsanitize=bounds)
CFLAGS_UBSAN += $(call cc-option, -fsanitize=object-size)
CFLAGS_UBSAN += $(call cc-option, -fsanitize=bool)
CFLAGS_UBSAN += $(call cc-option, -fsanitize=enum)
+endif
ifdef CONFIG_UBSAN_TRAP
CFLAGS_UBSAN += $(call cc-option, -fsanitize-undefined-trap-on-error)
--
2.20.1
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v3 3/6] lkdtm/bugs: Add arithmetic overflow and array bounds checks
2020-01-16 1:23 [PATCH v3 0/6] ubsan: Split out bounds checker Kees Cook
2020-01-16 1:23 ` [PATCH v3 1/6] ubsan: Add trap instrumentation option Kees Cook
2020-01-16 1:23 ` [PATCH v3 2/6] ubsan: Split "bounds" checker from other options Kees Cook
@ 2020-01-16 1:23 ` Kees Cook
2020-01-16 1:23 ` [PATCH v3 4/6] ubsan: Check panic_on_warn Kees Cook
` (2 subsequent siblings)
5 siblings, 0 replies; 13+ messages in thread
From: Kees Cook @ 2020-01-16 1:23 UTC (permalink / raw)
To: Andrew Morton
Cc: Kees Cook, Dmitry Vyukov, Andrey Ryabinin, Elena Petrova,
Alexander Potapenko, Dan Carpenter, Gustavo A. R. Silva,
Arnd Bergmann, Ard Biesheuvel, kasan-dev, linux-mm, linux-kernel,
kernel-hardening, syzkaller
Adds LKDTM tests for arithmetic overflow (both signed and unsigned),
as well as array bounds checking.
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Dmitry Vyukov <dvyukov@google.com>
---
drivers/misc/lkdtm/bugs.c | 75 ++++++++++++++++++++++++++++++++++++++
drivers/misc/lkdtm/core.c | 3 ++
drivers/misc/lkdtm/lkdtm.h | 3 ++
3 files changed, 81 insertions(+)
diff --git a/drivers/misc/lkdtm/bugs.c b/drivers/misc/lkdtm/bugs.c
index a4fdad04809a..aeee2b1c7663 100644
--- a/drivers/misc/lkdtm/bugs.c
+++ b/drivers/misc/lkdtm/bugs.c
@@ -11,6 +11,7 @@
#include <linux/sched/signal.h>
#include <linux/sched/task_stack.h>
#include <linux/uaccess.h>
+#include <linux/slab.h>
#ifdef CONFIG_X86_32
#include <asm/desc.h>
@@ -175,6 +176,80 @@ void lkdtm_HUNG_TASK(void)
schedule();
}
+volatile unsigned int huge = INT_MAX - 2;
+volatile unsigned int ignored;
+
+void lkdtm_OVERFLOW_SIGNED(void)
+{
+ int value;
+
+ value = huge;
+ pr_info("Normal signed addition ...\n");
+ value += 1;
+ ignored = value;
+
+ pr_info("Overflowing signed addition ...\n");
+ value += 4;
+ ignored = value;
+}
+
+
+void lkdtm_OVERFLOW_UNSIGNED(void)
+{
+ unsigned int value;
+
+ value = huge;
+ pr_info("Normal unsigned addition ...\n");
+ value += 1;
+ ignored = value;
+
+ pr_info("Overflowing unsigned addition ...\n");
+ value += 4;
+ ignored = value;
+}
+
+/* Intentially using old-style flex array definition of 1 byte. */
+struct array_bounds_flex_array {
+ int one;
+ int two;
+ char data[1];
+};
+
+struct array_bounds {
+ int one;
+ int two;
+ char data[8];
+ int three;
+};
+
+void lkdtm_ARRAY_BOUNDS(void)
+{
+ struct array_bounds_flex_array *not_checked;
+ struct array_bounds *checked;
+ volatile int i;
+
+ not_checked = kmalloc(sizeof(*not_checked) * 2, GFP_KERNEL);
+ checked = kmalloc(sizeof(*checked) * 2, GFP_KERNEL);
+
+ pr_info("Array access within bounds ...\n");
+ /* For both, touch all bytes in the actual member size. */
+ for (i = 0; i < sizeof(checked->data); i++)
+ checked->data[i] = 'A';
+ /*
+ * For the uninstrumented flex array member, also touch 1 byte
+ * beyond to verify it is correctly uninstrumented.
+ */
+ for (i = 0; i < sizeof(not_checked->data) + 1; i++)
+ not_checked->data[i] = 'A';
+
+ pr_info("Array access beyond bounds ...\n");
+ for (i = 0; i < sizeof(checked->data) + 1; i++)
+ checked->data[i] = 'B';
+
+ kfree(not_checked);
+ kfree(checked);
+}
+
void lkdtm_CORRUPT_LIST_ADD(void)
{
/*
diff --git a/drivers/misc/lkdtm/core.c b/drivers/misc/lkdtm/core.c
index ee0d6e721441..2e04719b503c 100644
--- a/drivers/misc/lkdtm/core.c
+++ b/drivers/misc/lkdtm/core.c
@@ -129,6 +129,9 @@ static const struct crashtype crashtypes[] = {
CRASHTYPE(HARDLOCKUP),
CRASHTYPE(SPINLOCKUP),
CRASHTYPE(HUNG_TASK),
+ CRASHTYPE(OVERFLOW_SIGNED),
+ CRASHTYPE(OVERFLOW_UNSIGNED),
+ CRASHTYPE(ARRAY_BOUNDS),
CRASHTYPE(EXEC_DATA),
CRASHTYPE(EXEC_STACK),
CRASHTYPE(EXEC_KMALLOC),
diff --git a/drivers/misc/lkdtm/lkdtm.h b/drivers/misc/lkdtm/lkdtm.h
index c56d23e37643..8391081c6f13 100644
--- a/drivers/misc/lkdtm/lkdtm.h
+++ b/drivers/misc/lkdtm/lkdtm.h
@@ -22,6 +22,9 @@ void lkdtm_SOFTLOCKUP(void);
void lkdtm_HARDLOCKUP(void);
void lkdtm_SPINLOCKUP(void);
void lkdtm_HUNG_TASK(void);
+void lkdtm_OVERFLOW_SIGNED(void);
+void lkdtm_OVERFLOW_UNSIGNED(void);
+void lkdtm_ARRAY_BOUNDS(void);
void lkdtm_CORRUPT_LIST_ADD(void);
void lkdtm_CORRUPT_LIST_DEL(void);
void lkdtm_CORRUPT_USER_DS(void);
--
2.20.1
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v3 4/6] ubsan: Check panic_on_warn
2020-01-16 1:23 [PATCH v3 0/6] ubsan: Split out bounds checker Kees Cook
` (2 preceding siblings ...)
2020-01-16 1:23 ` [PATCH v3 3/6] lkdtm/bugs: Add arithmetic overflow and array bounds checks Kees Cook
@ 2020-01-16 1:23 ` Kees Cook
2020-01-16 1:23 ` [PATCH v3 5/6] kasan: Unset panic_on_warn before calling panic() Kees Cook
2020-01-16 1:23 ` [PATCH v3 6/6] ubsan: Include bug type in report header Kees Cook
5 siblings, 0 replies; 13+ messages in thread
From: Kees Cook @ 2020-01-16 1:23 UTC (permalink / raw)
To: Andrew Morton
Cc: Kees Cook, Andrey Ryabinin, Elena Petrova, Alexander Potapenko,
Dan Carpenter, Gustavo A. R. Silva, Arnd Bergmann,
Ard Biesheuvel, kasan-dev, linux-mm, linux-kernel,
kernel-hardening, syzkaller
Syzkaller expects kernel warnings to panic when the panic_on_warn
sysctl is set. More work is needed here to have UBSan reuse the WARN
infrastructure, but for now, just check the flag manually.
Link: https://lore.kernel.org/lkml/CACT4Y+bsLJ-wFx_TaXqax3JByUOWB3uk787LsyMVcfW6JzzGvg@mail.gmail.com
Signed-off-by: Kees Cook <keescook@chromium.org>
---
lib/ubsan.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/lib/ubsan.c b/lib/ubsan.c
index 7b9b58aee72c..429663eef6a7 100644
--- a/lib/ubsan.c
+++ b/lib/ubsan.c
@@ -156,6 +156,17 @@ static void ubsan_epilogue(void)
"========================================\n");
current->in_ubsan--;
+
+ if (panic_on_warn) {
+ /*
+ * This thread may hit another WARN() in the panic path.
+ * Resetting this prevents additional WARN() from panicking the
+ * system on this thread. Other threads are blocked by the
+ * panic_mutex in panic().
+ */
+ panic_on_warn = 0;
+ panic("panic_on_warn set ...\n");
+ }
}
static void handle_overflow(struct overflow_data *data, void *lhs,
--
2.20.1
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v3 5/6] kasan: Unset panic_on_warn before calling panic()
2020-01-16 1:23 [PATCH v3 0/6] ubsan: Split out bounds checker Kees Cook
` (3 preceding siblings ...)
2020-01-16 1:23 ` [PATCH v3 4/6] ubsan: Check panic_on_warn Kees Cook
@ 2020-01-16 1:23 ` Kees Cook
2020-01-16 5:23 ` Dmitry Vyukov
2020-01-16 1:23 ` [PATCH v3 6/6] ubsan: Include bug type in report header Kees Cook
5 siblings, 1 reply; 13+ messages in thread
From: Kees Cook @ 2020-01-16 1:23 UTC (permalink / raw)
To: Andrew Morton
Cc: Kees Cook, Andrey Ryabinin, Elena Petrova, Alexander Potapenko,
Dan Carpenter, Gustavo A. R. Silva, Arnd Bergmann,
Ard Biesheuvel, kasan-dev, linux-mm, linux-kernel,
kernel-hardening, syzkaller
As done in the full WARN() handler, panic_on_warn needs to be cleared
before calling panic() to avoid recursive panics.
Signed-off-by: Kees Cook <keescook@chromium.org>
---
mm/kasan/report.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index 621782100eaa..844554e78893 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -92,8 +92,16 @@ static void end_report(unsigned long *flags)
pr_err("==================================================================\n");
add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE);
spin_unlock_irqrestore(&report_lock, *flags);
- if (panic_on_warn)
+ if (panic_on_warn) {
+ /*
+ * This thread may hit another WARN() in the panic path.
+ * Resetting this prevents additional WARN() from panicking the
+ * system on this thread. Other threads are blocked by the
+ * panic_mutex in panic().
+ */
+ panic_on_warn = 0;
panic("panic_on_warn set ...\n");
+ }
kasan_enable_current();
}
--
2.20.1
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [PATCH v3 5/6] kasan: Unset panic_on_warn before calling panic()
2020-01-16 1:23 ` [PATCH v3 5/6] kasan: Unset panic_on_warn before calling panic() Kees Cook
@ 2020-01-16 5:23 ` Dmitry Vyukov
2020-01-16 23:49 ` Kees Cook
0 siblings, 1 reply; 13+ messages in thread
From: Dmitry Vyukov @ 2020-01-16 5:23 UTC (permalink / raw)
To: Kees Cook
Cc: Andrew Morton, Andrey Ryabinin, Elena Petrova,
Alexander Potapenko, Dan Carpenter, Gustavo A. R. Silva,
Arnd Bergmann, Ard Biesheuvel, kasan-dev, Linux-MM, LKML,
kernel-hardening, syzkaller
On Thu, Jan 16, 2020 at 2:24 AM Kees Cook <keescook@chromium.org> wrote:
>
> As done in the full WARN() handler, panic_on_warn needs to be cleared
> before calling panic() to avoid recursive panics.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> mm/kasan/report.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> index 621782100eaa..844554e78893 100644
> --- a/mm/kasan/report.c
> +++ b/mm/kasan/report.c
> @@ -92,8 +92,16 @@ static void end_report(unsigned long *flags)
> pr_err("==================================================================\n");
> add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE);
> spin_unlock_irqrestore(&report_lock, *flags);
> - if (panic_on_warn)
> + if (panic_on_warn) {
> + /*
> + * This thread may hit another WARN() in the panic path.
> + * Resetting this prevents additional WARN() from panicking the
> + * system on this thread. Other threads are blocked by the
> + * panic_mutex in panic().
I don't understand part about other threads.
Other threads are not necessary inside of panic(). And in fact since
we reset panic_on_warn, they will not get there even if they should.
If I am reading this correctly, once one thread prints a warning and
is going to panic, other threads may now print infinite amounts of
warning and proceed past them freely. Why is this the behavior we
want?
> + */
> + panic_on_warn = 0;
> panic("panic_on_warn set ...\n");
> + }
> kasan_enable_current();
> }
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH v3 5/6] kasan: Unset panic_on_warn before calling panic()
2020-01-16 5:23 ` Dmitry Vyukov
@ 2020-01-16 23:49 ` Kees Cook
2020-01-17 9:54 ` Dmitry Vyukov
0 siblings, 1 reply; 13+ messages in thread
From: Kees Cook @ 2020-01-16 23:49 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Andrew Morton, Andrey Ryabinin, Elena Petrova,
Alexander Potapenko, Dan Carpenter, Gustavo A. R. Silva,
Arnd Bergmann, Ard Biesheuvel, kasan-dev, Linux-MM, LKML,
kernel-hardening, syzkaller
On Thu, Jan 16, 2020 at 06:23:01AM +0100, Dmitry Vyukov wrote:
> On Thu, Jan 16, 2020 at 2:24 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > As done in the full WARN() handler, panic_on_warn needs to be cleared
> > before calling panic() to avoid recursive panics.
> >
> > Signed-off-by: Kees Cook <keescook@chromium.org>
> > ---
> > mm/kasan/report.c | 10 +++++++++-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> > index 621782100eaa..844554e78893 100644
> > --- a/mm/kasan/report.c
> > +++ b/mm/kasan/report.c
> > @@ -92,8 +92,16 @@ static void end_report(unsigned long *flags)
> > pr_err("==================================================================\n");
> > add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE);
> > spin_unlock_irqrestore(&report_lock, *flags);
> > - if (panic_on_warn)
> > + if (panic_on_warn) {
> > + /*
> > + * This thread may hit another WARN() in the panic path.
> > + * Resetting this prevents additional WARN() from panicking the
> > + * system on this thread. Other threads are blocked by the
> > + * panic_mutex in panic().
>
> I don't understand part about other threads.
> Other threads are not necessary inside of panic(). And in fact since
> we reset panic_on_warn, they will not get there even if they should.
> If I am reading this correctly, once one thread prints a warning and
> is going to panic, other threads may now print infinite amounts of
> warning and proceed past them freely. Why is this the behavior we
> want?
AIUI, the issue is the current thread hitting another WARN and blocking
on trying to call panic again. WARNs encountered during the execution of
panic() need to not attempt to call panic() again.
-Kees
>
> > + */
> > + panic_on_warn = 0;
> > panic("panic_on_warn set ...\n");
> > + }
> > kasan_enable_current();
> > }
--
Kees Cook
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH v3 5/6] kasan: Unset panic_on_warn before calling panic()
2020-01-16 23:49 ` Kees Cook
@ 2020-01-17 9:54 ` Dmitry Vyukov
2020-01-17 21:20 ` Kees Cook
0 siblings, 1 reply; 13+ messages in thread
From: Dmitry Vyukov @ 2020-01-17 9:54 UTC (permalink / raw)
To: Kees Cook
Cc: Andrew Morton, Andrey Ryabinin, Elena Petrova,
Alexander Potapenko, Dan Carpenter, Gustavo A. R. Silva,
Arnd Bergmann, Ard Biesheuvel, kasan-dev, Linux-MM, LKML,
kernel-hardening, syzkaller
On Fri, Jan 17, 2020 at 12:49 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Thu, Jan 16, 2020 at 06:23:01AM +0100, Dmitry Vyukov wrote:
> > On Thu, Jan 16, 2020 at 2:24 AM Kees Cook <keescook@chromium.org> wrote:
> > >
> > > As done in the full WARN() handler, panic_on_warn needs to be cleared
> > > before calling panic() to avoid recursive panics.
> > >
> > > Signed-off-by: Kees Cook <keescook@chromium.org>
> > > ---
> > > mm/kasan/report.c | 10 +++++++++-
> > > 1 file changed, 9 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> > > index 621782100eaa..844554e78893 100644
> > > --- a/mm/kasan/report.c
> > > +++ b/mm/kasan/report.c
> > > @@ -92,8 +92,16 @@ static void end_report(unsigned long *flags)
> > > pr_err("==================================================================\n");
> > > add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE);
> > > spin_unlock_irqrestore(&report_lock, *flags);
> > > - if (panic_on_warn)
> > > + if (panic_on_warn) {
> > > + /*
> > > + * This thread may hit another WARN() in the panic path.
> > > + * Resetting this prevents additional WARN() from panicking the
> > > + * system on this thread. Other threads are blocked by the
> > > + * panic_mutex in panic().
> >
> > I don't understand part about other threads.
> > Other threads are not necessary inside of panic(). And in fact since
> > we reset panic_on_warn, they will not get there even if they should.
> > If I am reading this correctly, once one thread prints a warning and
> > is going to panic, other threads may now print infinite amounts of
> > warning and proceed past them freely. Why is this the behavior we
> > want?
>
> AIUI, the issue is the current thread hitting another WARN and blocking
> on trying to call panic again. WARNs encountered during the execution of
> panic() need to not attempt to call panic() again.
Yes, but the variable is global and affects other threads and the
comment talks about other threads, and that's the part I am confused
about (for both comment wording and the actual behavior). For the
"same thread hitting another warning" case we need a per-task flag or
something.
> -Kees
>
> >
> > > + */
> > > + panic_on_warn = 0;
> > > panic("panic_on_warn set ...\n");
> > > + }
> > > kasan_enable_current();
> > > }
>
> --
> Kees Cook
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH v3 5/6] kasan: Unset panic_on_warn before calling panic()
2020-01-17 9:54 ` Dmitry Vyukov
@ 2020-01-17 21:20 ` Kees Cook
2020-01-18 9:19 ` Dmitry Vyukov
0 siblings, 1 reply; 13+ messages in thread
From: Kees Cook @ 2020-01-17 21:20 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Andrew Morton, Andrey Ryabinin, Elena Petrova,
Alexander Potapenko, Dan Carpenter, Gustavo A. R. Silva,
Arnd Bergmann, Ard Biesheuvel, kasan-dev, Linux-MM, LKML,
kernel-hardening, syzkaller
On Fri, Jan 17, 2020 at 10:54:36AM +0100, Dmitry Vyukov wrote:
> On Fri, Jan 17, 2020 at 12:49 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Thu, Jan 16, 2020 at 06:23:01AM +0100, Dmitry Vyukov wrote:
> > > On Thu, Jan 16, 2020 at 2:24 AM Kees Cook <keescook@chromium.org> wrote:
> > > >
> > > > As done in the full WARN() handler, panic_on_warn needs to be cleared
> > > > before calling panic() to avoid recursive panics.
> > > >
> > > > Signed-off-by: Kees Cook <keescook@chromium.org>
> > > > ---
> > > > mm/kasan/report.c | 10 +++++++++-
> > > > 1 file changed, 9 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> > > > index 621782100eaa..844554e78893 100644
> > > > --- a/mm/kasan/report.c
> > > > +++ b/mm/kasan/report.c
> > > > @@ -92,8 +92,16 @@ static void end_report(unsigned long *flags)
> > > > pr_err("==================================================================\n");
> > > > add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE);
> > > > spin_unlock_irqrestore(&report_lock, *flags);
> > > > - if (panic_on_warn)
> > > > + if (panic_on_warn) {
> > > > + /*
> > > > + * This thread may hit another WARN() in the panic path.
> > > > + * Resetting this prevents additional WARN() from panicking the
> > > > + * system on this thread. Other threads are blocked by the
> > > > + * panic_mutex in panic().
> > >
> > > I don't understand part about other threads.
> > > Other threads are not necessary inside of panic(). And in fact since
> > > we reset panic_on_warn, they will not get there even if they should.
> > > If I am reading this correctly, once one thread prints a warning and
> > > is going to panic, other threads may now print infinite amounts of
> > > warning and proceed past them freely. Why is this the behavior we
> > > want?
> >
> > AIUI, the issue is the current thread hitting another WARN and blocking
> > on trying to call panic again. WARNs encountered during the execution of
> > panic() need to not attempt to call panic() again.
>
> Yes, but the variable is global and affects other threads and the
> comment talks about other threads, and that's the part I am confused
> about (for both comment wording and the actual behavior). For the
> "same thread hitting another warning" case we need a per-task flag or
> something.
This is duplicating the common panic-on-warn logic (see the generic bug
code), so I'd like to just have the same behavior between the three
implementations of panic-on-warn (generic bug, kasan, ubsan), and then
work to merge them into a common handler, and then perhaps fix the
details of the behavior. I think it's more correct to allow the panicing
thread to complete than to care about what the other threads are doing.
Right now, a WARN within the panic code will either a) hang the machine,
or b) not panic, allowing the rest of the threads to continue, maybe
then hitting other WARNs and hanging. The generic bug code does not
suffer from this.
-Kees
>
> > -Kees
> >
> > >
> > > > + */
> > > > + panic_on_warn = 0;
> > > > panic("panic_on_warn set ...\n");
> > > > + }
> > > > kasan_enable_current();
> > > > }
> >
> > --
> > Kees Cook
--
Kees Cook
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH v3 5/6] kasan: Unset panic_on_warn before calling panic()
2020-01-17 21:20 ` Kees Cook
@ 2020-01-18 9:19 ` Dmitry Vyukov
0 siblings, 0 replies; 13+ messages in thread
From: Dmitry Vyukov @ 2020-01-18 9:19 UTC (permalink / raw)
To: Kees Cook
Cc: Andrew Morton, Andrey Ryabinin, Elena Petrova,
Alexander Potapenko, Dan Carpenter, Gustavo A. R. Silva,
Arnd Bergmann, Ard Biesheuvel, kasan-dev, Linux-MM, LKML,
kernel-hardening, syzkaller
On Fri, Jan 17, 2020 at 10:20 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, Jan 17, 2020 at 10:54:36AM +0100, Dmitry Vyukov wrote:
> > On Fri, Jan 17, 2020 at 12:49 AM Kees Cook <keescook@chromium.org> wrote:
> > >
> > > On Thu, Jan 16, 2020 at 06:23:01AM +0100, Dmitry Vyukov wrote:
> > > > On Thu, Jan 16, 2020 at 2:24 AM Kees Cook <keescook@chromium.org> wrote:
> > > > >
> > > > > As done in the full WARN() handler, panic_on_warn needs to be cleared
> > > > > before calling panic() to avoid recursive panics.
> > > > >
> > > > > Signed-off-by: Kees Cook <keescook@chromium.org>
> > > > > ---
> > > > > mm/kasan/report.c | 10 +++++++++-
> > > > > 1 file changed, 9 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> > > > > index 621782100eaa..844554e78893 100644
> > > > > --- a/mm/kasan/report.c
> > > > > +++ b/mm/kasan/report.c
> > > > > @@ -92,8 +92,16 @@ static void end_report(unsigned long *flags)
> > > > > pr_err("==================================================================\n");
> > > > > add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE);
> > > > > spin_unlock_irqrestore(&report_lock, *flags);
> > > > > - if (panic_on_warn)
> > > > > + if (panic_on_warn) {
> > > > > + /*
> > > > > + * This thread may hit another WARN() in the panic path.
> > > > > + * Resetting this prevents additional WARN() from panicking the
> > > > > + * system on this thread. Other threads are blocked by the
> > > > > + * panic_mutex in panic().
> > > >
> > > > I don't understand part about other threads.
> > > > Other threads are not necessary inside of panic(). And in fact since
> > > > we reset panic_on_warn, they will not get there even if they should.
> > > > If I am reading this correctly, once one thread prints a warning and
> > > > is going to panic, other threads may now print infinite amounts of
> > > > warning and proceed past them freely. Why is this the behavior we
> > > > want?
> > >
> > > AIUI, the issue is the current thread hitting another WARN and blocking
> > > on trying to call panic again. WARNs encountered during the execution of
> > > panic() need to not attempt to call panic() again.
> >
> > Yes, but the variable is global and affects other threads and the
> > comment talks about other threads, and that's the part I am confused
> > about (for both comment wording and the actual behavior). For the
> > "same thread hitting another warning" case we need a per-task flag or
> > something.
>
> This is duplicating the common panic-on-warn logic (see the generic bug
> code), so I'd like to just have the same behavior between the three
> implementations of panic-on-warn (generic bug, kasan, ubsan), and then
> work to merge them into a common handler, and then perhaps fix the
> details of the behavior. I think it's more correct to allow the panicing
> thread to complete than to care about what the other threads are doing.
> Right now, a WARN within the panic code will either a) hang the machine,
> or b) not panic, allowing the rest of the threads to continue, maybe
> then hitting other WARNs and hanging. The generic bug code does not
> suffer from this.
I see. Then:
Acked-by: Dmitry Vyukov <dvyukov@google.com>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v3 6/6] ubsan: Include bug type in report header
2020-01-16 1:23 [PATCH v3 0/6] ubsan: Split out bounds checker Kees Cook
` (4 preceding siblings ...)
2020-01-16 1:23 ` [PATCH v3 5/6] kasan: Unset panic_on_warn before calling panic() Kees Cook
@ 2020-01-16 1:23 ` Kees Cook
2020-01-16 12:32 ` Andrey Konovalov
5 siblings, 1 reply; 13+ messages in thread
From: Kees Cook @ 2020-01-16 1:23 UTC (permalink / raw)
To: Andrew Morton
Cc: Kees Cook, Dmitry Vyukov, Andrey Ryabinin, Elena Petrova,
Alexander Potapenko, Dan Carpenter, Gustavo A. R. Silva,
Arnd Bergmann, Ard Biesheuvel, kasan-dev, linux-mm, linux-kernel,
kernel-hardening, syzkaller
When syzbot tries to figure out how to deduplicate bug reports, it
prefers seeing a hint about a specific bug type (we can do better than
just "UBSAN"). This lifts the handler reason into the UBSAN report line
that includes the file path that tripped a check. Unfortunately, UBSAN
does not provide function names.
Suggested-by: Dmitry Vyukov <dvyukov@google.com>
Link: https://lore.kernel.org/lkml/CACT4Y+bsLJ-wFx_TaXqax3JByUOWB3uk787LsyMVcfW6JzzGvg@mail.gmail.com
Signed-off-by: Kees Cook <keescook@chromium.org>
---
lib/ubsan.c | 36 +++++++++++++++---------------------
1 file changed, 15 insertions(+), 21 deletions(-)
diff --git a/lib/ubsan.c b/lib/ubsan.c
index 429663eef6a7..057d5375bfc6 100644
--- a/lib/ubsan.c
+++ b/lib/ubsan.c
@@ -45,13 +45,6 @@ static bool was_reported(struct source_location *location)
return test_and_set_bit(REPORTED_BIT, &location->reported);
}
-static void print_source_location(const char *prefix,
- struct source_location *loc)
-{
- pr_err("%s %s:%d:%d\n", prefix, loc->file_name,
- loc->line & LINE_MASK, loc->column & COLUMN_MASK);
-}
-
static bool suppress_report(struct source_location *loc)
{
return current->in_ubsan || was_reported(loc);
@@ -140,13 +133,14 @@ static void val_to_string(char *str, size_t size, struct type_descriptor *type,
}
}
-static void ubsan_prologue(struct source_location *location)
+static void ubsan_prologue(struct source_location *loc, const char *reason)
{
current->in_ubsan++;
pr_err("========================================"
"========================================\n");
- print_source_location("UBSAN: Undefined behaviour in", location);
+ pr_err("UBSAN: %s in %s:%d:%d\n", reason, loc->file_name,
+ loc->line & LINE_MASK, loc->column & COLUMN_MASK);
}
static void ubsan_epilogue(void)
@@ -180,12 +174,12 @@ static void handle_overflow(struct overflow_data *data, void *lhs,
if (suppress_report(&data->location))
return;
- ubsan_prologue(&data->location);
+ ubsan_prologue(&data->location, type_is_signed(type) ?
+ "signed integer overflow" :
+ "unsigned integer overflow");
val_to_string(lhs_val_str, sizeof(lhs_val_str), type, lhs);
val_to_string(rhs_val_str, sizeof(rhs_val_str), type, rhs);
- pr_err("%s integer overflow:\n",
- type_is_signed(type) ? "signed" : "unsigned");
pr_err("%s %c %s cannot be represented in type %s\n",
lhs_val_str,
op,
@@ -225,7 +219,7 @@ void __ubsan_handle_negate_overflow(struct overflow_data *data,
if (suppress_report(&data->location))
return;
- ubsan_prologue(&data->location);
+ ubsan_prologue(&data->location, "negation overflow");
val_to_string(old_val_str, sizeof(old_val_str), data->type, old_val);
@@ -245,7 +239,7 @@ void __ubsan_handle_divrem_overflow(struct overflow_data *data,
if (suppress_report(&data->location))
return;
- ubsan_prologue(&data->location);
+ ubsan_prologue(&data->location, "division overflow");
val_to_string(rhs_val_str, sizeof(rhs_val_str), data->type, rhs);
@@ -264,7 +258,7 @@ static void handle_null_ptr_deref(struct type_mismatch_data_common *data)
if (suppress_report(data->location))
return;
- ubsan_prologue(data->location);
+ ubsan_prologue(data->location, "NULL pointer dereference");
pr_err("%s null pointer of type %s\n",
type_check_kinds[data->type_check_kind],
@@ -279,7 +273,7 @@ static void handle_misaligned_access(struct type_mismatch_data_common *data,
if (suppress_report(data->location))
return;
- ubsan_prologue(data->location);
+ ubsan_prologue(data->location, "misaligned access");
pr_err("%s misaligned address %p for type %s\n",
type_check_kinds[data->type_check_kind],
@@ -295,7 +289,7 @@ static void handle_object_size_mismatch(struct type_mismatch_data_common *data,
if (suppress_report(data->location))
return;
- ubsan_prologue(data->location);
+ ubsan_prologue(data->location, "object size mismatch");
pr_err("%s address %p with insufficient space\n",
type_check_kinds[data->type_check_kind],
(void *) ptr);
@@ -354,7 +348,7 @@ void __ubsan_handle_out_of_bounds(struct out_of_bounds_data *data, void *index)
if (suppress_report(&data->location))
return;
- ubsan_prologue(&data->location);
+ ubsan_prologue(&data->location, "array index out of bounds");
val_to_string(index_str, sizeof(index_str), data->index_type, index);
pr_err("index %s is out of range for type %s\n", index_str,
@@ -375,7 +369,7 @@ void __ubsan_handle_shift_out_of_bounds(struct shift_out_of_bounds_data *data,
if (suppress_report(&data->location))
goto out;
- ubsan_prologue(&data->location);
+ ubsan_prologue(&data->location, "shift out of bounds");
val_to_string(rhs_str, sizeof(rhs_str), rhs_type, rhs);
val_to_string(lhs_str, sizeof(lhs_str), lhs_type, lhs);
@@ -407,7 +401,7 @@ EXPORT_SYMBOL(__ubsan_handle_shift_out_of_bounds);
void __ubsan_handle_builtin_unreachable(struct unreachable_data *data)
{
- ubsan_prologue(&data->location);
+ ubsan_prologue(&data->location, "unreachable");
pr_err("calling __builtin_unreachable()\n");
ubsan_epilogue();
panic("can't return from __builtin_unreachable()");
@@ -422,7 +416,7 @@ void __ubsan_handle_load_invalid_value(struct invalid_value_data *data,
if (suppress_report(&data->location))
return;
- ubsan_prologue(&data->location);
+ ubsan_prologue(&data->location, "invalid load");
val_to_string(val_str, sizeof(val_str), data->type, val);
--
2.20.1
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [PATCH v3 6/6] ubsan: Include bug type in report header
2020-01-16 1:23 ` [PATCH v3 6/6] ubsan: Include bug type in report header Kees Cook
@ 2020-01-16 12:32 ` Andrey Konovalov
0 siblings, 0 replies; 13+ messages in thread
From: Andrey Konovalov @ 2020-01-16 12:32 UTC (permalink / raw)
To: Kees Cook
Cc: Andrew Morton, Dmitry Vyukov, Andrey Ryabinin, Elena Petrova,
Alexander Potapenko, Dan Carpenter, Gustavo A. R. Silva,
Arnd Bergmann, Ard Biesheuvel, kasan-dev,
Linux Memory Management List, LKML, kernel-hardening, syzkaller
On Thu, Jan 16, 2020 at 2:24 AM Kees Cook <keescook@chromium.org> wrote:
>
> When syzbot tries to figure out how to deduplicate bug reports, it
> prefers seeing a hint about a specific bug type (we can do better than
> just "UBSAN"). This lifts the handler reason into the UBSAN report line
> that includes the file path that tripped a check. Unfortunately, UBSAN
> does not provide function names.
>
> Suggested-by: Dmitry Vyukov <dvyukov@google.com>
> Link: https://lore.kernel.org/lkml/CACT4Y+bsLJ-wFx_TaXqax3JByUOWB3uk787LsyMVcfW6JzzGvg@mail.gmail.com
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> lib/ubsan.c | 36 +++++++++++++++---------------------
> 1 file changed, 15 insertions(+), 21 deletions(-)
>
> diff --git a/lib/ubsan.c b/lib/ubsan.c
> index 429663eef6a7..057d5375bfc6 100644
> --- a/lib/ubsan.c
> +++ b/lib/ubsan.c
> @@ -45,13 +45,6 @@ static bool was_reported(struct source_location *location)
> return test_and_set_bit(REPORTED_BIT, &location->reported);
> }
>
> -static void print_source_location(const char *prefix,
> - struct source_location *loc)
> -{
> - pr_err("%s %s:%d:%d\n", prefix, loc->file_name,
> - loc->line & LINE_MASK, loc->column & COLUMN_MASK);
> -}
> -
> static bool suppress_report(struct source_location *loc)
> {
> return current->in_ubsan || was_reported(loc);
> @@ -140,13 +133,14 @@ static void val_to_string(char *str, size_t size, struct type_descriptor *type,
> }
> }
>
> -static void ubsan_prologue(struct source_location *location)
> +static void ubsan_prologue(struct source_location *loc, const char *reason)
> {
> current->in_ubsan++;
>
> pr_err("========================================"
> "========================================\n");
> - print_source_location("UBSAN: Undefined behaviour in", location);
> + pr_err("UBSAN: %s in %s:%d:%d\n", reason, loc->file_name,
> + loc->line & LINE_MASK, loc->column & COLUMN_MASK);
> }
>
> static void ubsan_epilogue(void)
> @@ -180,12 +174,12 @@ static void handle_overflow(struct overflow_data *data, void *lhs,
> if (suppress_report(&data->location))
> return;
>
> - ubsan_prologue(&data->location);
> + ubsan_prologue(&data->location, type_is_signed(type) ?
> + "signed integer overflow" :
> + "unsigned integer overflow");
>
> val_to_string(lhs_val_str, sizeof(lhs_val_str), type, lhs);
> val_to_string(rhs_val_str, sizeof(rhs_val_str), type, rhs);
> - pr_err("%s integer overflow:\n",
> - type_is_signed(type) ? "signed" : "unsigned");
> pr_err("%s %c %s cannot be represented in type %s\n",
> lhs_val_str,
> op,
> @@ -225,7 +219,7 @@ void __ubsan_handle_negate_overflow(struct overflow_data *data,
> if (suppress_report(&data->location))
> return;
>
> - ubsan_prologue(&data->location);
> + ubsan_prologue(&data->location, "negation overflow");
>
> val_to_string(old_val_str, sizeof(old_val_str), data->type, old_val);
>
> @@ -245,7 +239,7 @@ void __ubsan_handle_divrem_overflow(struct overflow_data *data,
> if (suppress_report(&data->location))
> return;
>
> - ubsan_prologue(&data->location);
> + ubsan_prologue(&data->location, "division overflow");
>
> val_to_string(rhs_val_str, sizeof(rhs_val_str), data->type, rhs);
>
> @@ -264,7 +258,7 @@ static void handle_null_ptr_deref(struct type_mismatch_data_common *data)
> if (suppress_report(data->location))
> return;
>
> - ubsan_prologue(data->location);
> + ubsan_prologue(data->location, "NULL pointer dereference");
Not crucially important, but I think it makes sense to use the
single-word-with-hyphens bug type format like in KASAN here, e.g.
null-ptr-deref, misaligned-access, etc.
>
> pr_err("%s null pointer of type %s\n",
> type_check_kinds[data->type_check_kind],
> @@ -279,7 +273,7 @@ static void handle_misaligned_access(struct type_mismatch_data_common *data,
> if (suppress_report(data->location))
> return;
>
> - ubsan_prologue(data->location);
> + ubsan_prologue(data->location, "misaligned access");
>
> pr_err("%s misaligned address %p for type %s\n",
> type_check_kinds[data->type_check_kind],
> @@ -295,7 +289,7 @@ static void handle_object_size_mismatch(struct type_mismatch_data_common *data,
> if (suppress_report(data->location))
> return;
>
> - ubsan_prologue(data->location);
> + ubsan_prologue(data->location, "object size mismatch");
> pr_err("%s address %p with insufficient space\n",
> type_check_kinds[data->type_check_kind],
> (void *) ptr);
> @@ -354,7 +348,7 @@ void __ubsan_handle_out_of_bounds(struct out_of_bounds_data *data, void *index)
> if (suppress_report(&data->location))
> return;
>
> - ubsan_prologue(&data->location);
> + ubsan_prologue(&data->location, "array index out of bounds");
>
> val_to_string(index_str, sizeof(index_str), data->index_type, index);
> pr_err("index %s is out of range for type %s\n", index_str,
> @@ -375,7 +369,7 @@ void __ubsan_handle_shift_out_of_bounds(struct shift_out_of_bounds_data *data,
> if (suppress_report(&data->location))
> goto out;
>
> - ubsan_prologue(&data->location);
> + ubsan_prologue(&data->location, "shift out of bounds");
>
> val_to_string(rhs_str, sizeof(rhs_str), rhs_type, rhs);
> val_to_string(lhs_str, sizeof(lhs_str), lhs_type, lhs);
> @@ -407,7 +401,7 @@ EXPORT_SYMBOL(__ubsan_handle_shift_out_of_bounds);
>
> void __ubsan_handle_builtin_unreachable(struct unreachable_data *data)
> {
> - ubsan_prologue(&data->location);
> + ubsan_prologue(&data->location, "unreachable");
> pr_err("calling __builtin_unreachable()\n");
> ubsan_epilogue();
> panic("can't return from __builtin_unreachable()");
> @@ -422,7 +416,7 @@ void __ubsan_handle_load_invalid_value(struct invalid_value_data *data,
> if (suppress_report(&data->location))
> return;
>
> - ubsan_prologue(&data->location);
> + ubsan_prologue(&data->location, "invalid load");
>
> val_to_string(val_str, sizeof(val_str), data->type, val);
>
> --
> 2.20.1
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/20200116012321.26254-7-keescook%40chromium.org.
^ permalink raw reply [flat|nested] 13+ messages in thread