From: Kees Cook <keescook@chromium.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
Ard Biesheuvel <ardb@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
kernel test robot <lkp@intel.com>,
Peter Oberparleiter <oberpar@linux.ibm.com>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
kbuild-all@lists.01.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: lib/crypto/chacha.c:65:1: warning: the frame size of 1604 bytes is larger than 1024 bytes
Date: Thu, 27 Aug 2020 11:42:07 -0700 [thread overview]
Message-ID: <202008271138.0FA7400@keescook> (raw)
In-Reply-To: <CAHk-=wgXW=YLxGN0QVpp-1w5GDd2pf1W-FqY15poKzoVfik2qA@mail.gmail.com>
On Thu, Aug 27, 2020 at 10:55:32AM -0700, Linus Torvalds wrote:
> On Thu, Aug 27, 2020 at 10:34 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > How are you guys testing? I have UBSAN and GCOV on, and don't see
> > crazy frames on either i386 or x86-64.
>
> Oh, never mind. I also have COMPILE_TEST on, so it ends up disabling
> GCOV_PROFILE_ALL and UBSAN_SANITIZE_ALL.
>
> And yeah, this seems to be a gcc bug. It generates a ton of stack
> slots for temporaries. It's -fsanitize=object-size that seems to do
> it.
>
> And "-fstack-reuse=all" doesn't seem to make any difference.
>
> So I think
>
> (a) our stack size check is good to catch this
>
> (b) gcc and -fsanitize=object-size is basically an unusable combination
>
> and it's not a bug in the kernel.
Do you mean you checked both gcc and clang and it was only a problem with gcc?
(If so, I can tweak the "depends" below...)
This should let us avoid it, I'm currently testing:
diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
index 774315de555a..24091315c251 100644
--- a/lib/Kconfig.ubsan
+++ b/lib/Kconfig.ubsan
@@ -47,6 +47,19 @@ config UBSAN_BOUNDS
to the {str,mem}*cpy() family of functions (that is addressed
by CONFIG_FORTIFY_SOURCE).
+config UBSAN_OBJECT_SIZE
+ bool "Check for accesses beyond known object sizes"
+ default UBSAN
+ depends on !COMPILE_TEST
+ help
+ This option enables detection of cases where accesses may
+ happen beyond the end of an object's size, which happens in
+ places like invalid downcasts, or calling function pointers
+ through invalid pointers.
+
+ This uses much more stack space, and isn't recommended for
+ cases were stack utilization depth is a concern.
+
config UBSAN_MISC
bool "Enable all other Undefined Behavior sanity checks"
default UBSAN
diff --git a/scripts/Makefile.ubsan b/scripts/Makefile.ubsan
index 27348029b2b8..3ff67e9b17fd 100644
--- a/scripts/Makefile.ubsan
+++ b/scripts/Makefile.ubsan
@@ -7,12 +7,15 @@ ifdef CONFIG_UBSAN_BOUNDS
CFLAGS_UBSAN += $(call cc-option, -fsanitize=bounds)
endif
+ifdef CONFIG_UBSAN_OBJECT_SIZE
+ CFLAGS_UBSAN += $(call cc-option, -fsanitize=object-size)
+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=object-size)
CFLAGS_UBSAN += $(call cc-option, -fsanitize=bool)
CFLAGS_UBSAN += $(call cc-option, -fsanitize=enum)
endif
--
Kees Cook
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: kbuild-all@lists.01.org
Subject: Re: lib/crypto/chacha.c:65:1: warning: the frame size of 1604 bytes is larger than 1024 bytes
Date: Thu, 27 Aug 2020 11:42:07 -0700 [thread overview]
Message-ID: <202008271138.0FA7400@keescook> (raw)
In-Reply-To: <CAHk-=wgXW=YLxGN0QVpp-1w5GDd2pf1W-FqY15poKzoVfik2qA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2765 bytes --]
On Thu, Aug 27, 2020 at 10:55:32AM -0700, Linus Torvalds wrote:
> On Thu, Aug 27, 2020 at 10:34 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > How are you guys testing? I have UBSAN and GCOV on, and don't see
> > crazy frames on either i386 or x86-64.
>
> Oh, never mind. I also have COMPILE_TEST on, so it ends up disabling
> GCOV_PROFILE_ALL and UBSAN_SANITIZE_ALL.
>
> And yeah, this seems to be a gcc bug. It generates a ton of stack
> slots for temporaries. It's -fsanitize=object-size that seems to do
> it.
>
> And "-fstack-reuse=all" doesn't seem to make any difference.
>
> So I think
>
> (a) our stack size check is good to catch this
>
> (b) gcc and -fsanitize=object-size is basically an unusable combination
>
> and it's not a bug in the kernel.
Do you mean you checked both gcc and clang and it was only a problem with gcc?
(If so, I can tweak the "depends" below...)
This should let us avoid it, I'm currently testing:
diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
index 774315de555a..24091315c251 100644
--- a/lib/Kconfig.ubsan
+++ b/lib/Kconfig.ubsan
@@ -47,6 +47,19 @@ config UBSAN_BOUNDS
to the {str,mem}*cpy() family of functions (that is addressed
by CONFIG_FORTIFY_SOURCE).
+config UBSAN_OBJECT_SIZE
+ bool "Check for accesses beyond known object sizes"
+ default UBSAN
+ depends on !COMPILE_TEST
+ help
+ This option enables detection of cases where accesses may
+ happen beyond the end of an object's size, which happens in
+ places like invalid downcasts, or calling function pointers
+ through invalid pointers.
+
+ This uses much more stack space, and isn't recommended for
+ cases were stack utilization depth is a concern.
+
config UBSAN_MISC
bool "Enable all other Undefined Behavior sanity checks"
default UBSAN
diff --git a/scripts/Makefile.ubsan b/scripts/Makefile.ubsan
index 27348029b2b8..3ff67e9b17fd 100644
--- a/scripts/Makefile.ubsan
+++ b/scripts/Makefile.ubsan
@@ -7,12 +7,15 @@ ifdef CONFIG_UBSAN_BOUNDS
CFLAGS_UBSAN += $(call cc-option, -fsanitize=bounds)
endif
+ifdef CONFIG_UBSAN_OBJECT_SIZE
+ CFLAGS_UBSAN += $(call cc-option, -fsanitize=object-size)
+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=object-size)
CFLAGS_UBSAN += $(call cc-option, -fsanitize=bool)
CFLAGS_UBSAN += $(call cc-option, -fsanitize=enum)
endif
--
Kees Cook
next prev parent reply other threads:[~2020-08-27 18:42 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-27 3:52 lib/crypto/chacha.c:65:1: warning: the frame size of 1604 bytes is larger than 1024 bytes kernel test robot
2020-08-27 3:52 ` kernel test robot
2020-08-27 8:05 ` Herbert Xu
2020-08-27 8:05 ` Herbert Xu
2020-08-27 8:10 ` Ard Biesheuvel
2020-08-27 8:10 ` Ard Biesheuvel
2020-08-27 8:24 ` Herbert Xu
2020-08-27 8:24 ` Herbert Xu
2020-08-27 17:34 ` Linus Torvalds
2020-08-27 17:34 ` Linus Torvalds
2020-08-27 17:55 ` Linus Torvalds
2020-08-27 17:55 ` Linus Torvalds
2020-08-27 18:42 ` Kees Cook [this message]
2020-08-27 18:42 ` Kees Cook
2020-08-27 19:02 ` Linus Torvalds
2020-08-27 19:02 ` Linus Torvalds
2020-08-27 19:32 ` Kees Cook
2020-08-27 19:32 ` Kees Cook
2020-08-27 19:11 ` Arnd Bergmann
2020-08-27 19:11 ` Arnd Bergmann
2020-08-27 19:34 ` Kees Cook
2020-08-27 19:34 ` Kees Cook
2020-08-27 20:08 ` Linus Torvalds
2020-08-27 20:08 ` Linus Torvalds
2020-08-27 8:33 ` Arnd Bergmann
2020-08-27 8:33 ` Arnd Bergmann
2020-08-27 8:42 ` Ard Biesheuvel
2020-08-27 8:42 ` Ard Biesheuvel
2020-08-27 9:19 ` Arnd Bergmann
2020-08-27 9:19 ` Arnd Bergmann
2020-08-27 10:41 ` Ard Biesheuvel
2020-08-27 10:41 ` Ard Biesheuvel
2020-08-27 11:51 ` Herbert Xu
2020-08-27 11:51 ` Herbert Xu
2020-08-27 16:25 ` Arnd Bergmann
2020-08-27 16:25 ` Arnd Bergmann
-- strict thread matches above, loose matches on Subject: below --
2020-09-19 17:27 kernel test robot
2020-09-19 17:27 ` kernel test robot
2020-10-18 19:13 kernel test robot
2020-10-18 19:13 ` kernel test robot
2020-10-19 15:47 ` Joe Perches
2020-10-19 15:47 ` Joe Perches
2020-10-20 8:00 ` David Laight
2020-10-20 10:13 ` Joe Perches
2020-10-20 10:13 ` Joe Perches
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=202008271138.0FA7400@keescook \
--to=keescook@chromium.org \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=aryabinin@virtuozzo.com \
--cc=herbert@gondor.apana.org.au \
--cc=kbuild-all@lists.01.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=oberpar@linux.ibm.com \
--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.