From: Andrey Ryabinin <aryabinin@virtuozzo.com>
To: Kees Cook <keescook@chromium.org>
Cc: Elena Petrova <lenaptr@google.com>,
Alexander Potapenko <glider@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Dan Carpenter <dan.carpenter@oracle.com>,
"Gustavo A. R. Silva" <gustavo@embeddedor.com>,
Arnd Bergmann <arnd@arndb.de>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Andrew Morton <akpm@linux-foundation.org>,
kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org,
kernel-hardening@lists.openwall.com
Subject: Re: [PATCH 1/3] ubsan: Add trap instrumentation option
Date: Thu, 21 Nov 2019 15:52:52 +0300 [thread overview]
Message-ID: <35fa415f-1dab-b93d-f565-f0754b886d1b@virtuozzo.com> (raw)
In-Reply-To: <20191120010636.27368-2-keescook@chromium.org>
On 11/20/19 4:06 AM, Kees Cook wrote:
> +config UBSAN_TRAP
> + bool "On Sanitizer warnings, stop the offending kernel thread"
That description seems inaccurate and confusing. It's not about kernel threads.
UBSAN may trigger in any context - kernel thread/user process/interrupts...
Probably most of the kernel code runs in the context of user process, so "stop the offending kernel thread"
doesn't sound right.
> + 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 over 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 into full thread-killing exceptions.
I think we should mention that enabling this option also has a potential to
turn some otherwise harmless bugs into more severe problems like lockups, kernel panic etc..
So the people who enable this would better understand what they signing up for.
next prev parent reply other threads:[~2019-11-21 12:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-20 1:06 [PATCH 0/3] ubsan: Split out bounds checker Kees Cook
2019-11-20 1:06 ` [PATCH 1/3] ubsan: Add trap instrumentation option Kees Cook
2019-11-21 12:52 ` Andrey Ryabinin [this message]
2019-11-21 17:20 ` Kees Cook
2019-11-21 17:57 ` Kees Cook
2019-11-20 1:06 ` [PATCH 2/3] ubsan: Split "bounds" checker from other options Kees Cook
2019-11-21 12:54 ` Andrey Ryabinin
2019-11-20 1:06 ` [PATCH 3/3] lkdtm/bugs: Add arithmetic overflow and array bounds checks Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=35fa415f-1dab-b93d-f565-f0754b886d1b@virtuozzo.com \
--to=aryabinin@virtuozzo.com \
--cc=akpm@linux-foundation.org \
--cc=ard.biesheuvel@linaro.org \
--cc=arnd@arndb.de \
--cc=dan.carpenter@oracle.com \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=gustavo@embeddedor.com \
--cc=kasan-dev@googlegroups.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=lenaptr@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).