From: Kees Cook <keescook@chromium.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: linux-kernel@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
Brendan Higgins <brendanhiggins@google.com>,
Shuah Khan <skhan@linuxfoundation.org>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Alan Maguire <alan.maguire@oracle.com>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Vitor Massaru Iha <vitor@massaru.org>,
linux-hardening@vger.kernel.org, linux-kselftest@vger.kernel.org,
kunit-dev@googlegroups.com
Subject: Re: [RFC 0/3] kunit vs structleak
Date: Wed, 27 Jan 2021 12:15:15 -0800 [thread overview]
Message-ID: <202101271213.4F331332E@keescook> (raw)
In-Reply-To: <20210125124533.101339-1-arnd@kernel.org>
On Mon, Jan 25, 2021 at 01:45:25PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> I ran into a couple of problems with kunit tests taking too much stack
> space, sometimes dangerously so. These the the three instances that
> cause an increase over the warning limit of some architectures:
>
> lib/bitfield_kunit.c:93:1: error: the frame size of 7440 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
> drivers/base/test/property-entry-test.c:481:1: error: the frame size of 2640 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
> drivers/thunderbolt/test.c:1529:1: error: the frame size of 1176 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
>
> Ideally there should be a way to rewrite the kunit infrastructure
> that avoids the explosion of stack data when the structleak plugin
> is used.
>
> A rather drastic measure would be to use Kconfig logic to make
> the two options mutually exclusive. This would clearly work, but
> is probably not needed.
>
> As a simpler workaround, this disables the plugin for the three
> files in which the excessive stack usage was observed.
>
> Arnd
>
> Arnd Bergmann (3):
> bitfield: build kunit tests without structleak plugin
> drivers/base: build kunit tests without structleak plugin
> thunderbolt: build kunit tests without structleak plugin
>
> drivers/base/test/Makefile | 1 +
> drivers/thunderbolt/Makefile | 1 +
> lib/Makefile | 1 +
> 3 files changed, 3 insertions(+)
I think I'd prefer centralizing the disabling, as done with the other
plugins, instead of sprinkling "open coded" command-line options around
the kernel's Makefiles. :)
For example:
diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
index 952e46876329..2d5009e3b593 100644
--- a/scripts/Makefile.gcc-plugins
+++ b/scripts/Makefile.gcc-plugins
@@ -21,6 +21,10 @@ gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL) \
+= -fplugin-arg-structleak_plugin-byref-all
gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK) \
+= -DSTRUCTLEAK_PLUGIN
+ifdef CONFIG_GCC_PLUGIN_STRUCTLEAK
+ DISABLE_STRUCTLEAK_PLUGIN += -fplugin-arg-structleak_plugin-disable
+endif
+export DISABLE_STRUCTLEAK_PLUGIN
gcc-plugin-$(CONFIG_GCC_PLUGIN_RANDSTRUCT) += randomize_layout_plugin.so
gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_RANDSTRUCT) \
And then use DISABLE_STRUCTLEAK_PLUGIN.
--
Kees Cook
next prev parent reply other threads:[~2021-01-27 20:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-25 12:45 [RFC 0/3] kunit vs structleak Arnd Bergmann
2021-01-25 12:45 ` [RFC 1/3] bitfield: build kunit tests without structleak plugin Arnd Bergmann
2021-01-25 12:45 ` [RFC 2/3] drivers/base: " Arnd Bergmann
2021-01-25 12:45 ` [RFC 3/3] thunderbolt: " Arnd Bergmann
2021-01-27 12:53 ` Mika Westerberg
2021-01-27 20:15 ` Kees Cook [this message]
2021-01-29 21:29 ` [RFC 0/3] kunit vs structleak Brendan Higgins
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=202101271213.4F331332E@keescook \
--to=keescook@chromium.org \
--cc=alan.maguire@oracle.com \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=brendanhiggins@google.com \
--cc=dmitry.torokhov@gmail.com \
--cc=geert+renesas@glider.be \
--cc=kunit-dev@googlegroups.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=skhan@linuxfoundation.org \
--cc=vitor@massaru.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.