From: Kees Cook <keescook@chromium.org>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "David Gow" <davidgow@google.com>,
"Eric Biederman" <ebiederm@xmission.com>,
"Daniel Latypov" <dlatypov@google.com>,
"Magnus Groß" <magnus.gross@rwth-aachen.de>,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
linux-kernel@vger.kernel.org, kunit-dev@googlegroups.com,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH v2] binfmt_elf: Introduce KUnit test
Date: Tue, 8 Mar 2022 14:12:54 -0800 [thread overview]
Message-ID: <202203081408.0B0FC34C@keescook> (raw)
In-Reply-To: <YifJqN+5ju4kHQ2y@localhost.localdomain>
On Wed, Mar 09, 2022 at 12:24:56AM +0300, Alexey Dobriyan wrote:
> On Thu, Mar 03, 2022 at 08:48:31PM -0800, Kees Cook wrote:
> > Adds simple KUnit test for some binfmt_elf internals: specifically a
> > regression test for the problem fixed by commit 8904d9cd90ee ("ELF:
> > fix overflow in total mapping size calculation").
>
> > + /* No headers, no size. */
> > + KUNIT_EXPECT_EQ(test, total_mapping_size(NULL, 0), 0);
>
> This is meaningless test. This whole function only makes sense
> if program headers are read and loading process advances far enough
> so that pointer is not NULL.
I think it's important to start adding incremental unit testing to core
kernel APIs. This is a case of adding a regression test for a specific
misbehavior. This is good, but in addition, testing should check any other
corner cases as well. Yes, the above EXPECT line is total nonsense, and
it makes sure that nonsense actually reports back the expected failure
state "0".
> Are we going to mock every single function in the kernel?
> Disgusting.
I'm not really interested in a slippery slope debate, but honestly, if we
_could_ mock everything in the kernel and create unit tests for everything
in the kernel, then yes, we should. It's certainly not feasible, but at
least _getting started_ on unit testing execve is worth it.
--
Kees Cook
prev parent reply other threads:[~2022-03-08 22:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-04 4:48 [PATCH v2] binfmt_elf: Introduce KUnit test Kees Cook
2022-03-04 7:52 ` David Gow
2022-03-08 21:24 ` Alexey Dobriyan
2022-03-08 22:12 ` Kees Cook [this message]
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=202203081408.0B0FC34C@keescook \
--to=keescook@chromium.org \
--cc=adobriyan@gmail.com \
--cc=davidgow@google.com \
--cc=dlatypov@google.com \
--cc=ebiederm@xmission.com \
--cc=kunit-dev@googlegroups.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=magnus.gross@rwth-aachen.de \
--cc=viro@zeniv.linux.org.uk \
/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).