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 2/3] ubsan: Split "bounds" checker from other options
Date: Thu, 21 Nov 2019 15:54:44 +0300 [thread overview]
Message-ID: <06a84afd-bc97-d2b5-3129-d23473f7acb5@virtuozzo.com> (raw)
In-Reply-To: <20191120010636.27368-3-keescook@chromium.org>
On 11/20/19 4:06 AM, Kees Cook wrote:
> 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>
next prev parent reply other threads:[~2019-11-21 12:55 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
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 [this message]
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=06a84afd-bc97-d2b5-3129-d23473f7acb5@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.