From: Kees Cook <keescook@chromium.org>
To: Daniel Latypov <dlatypov@google.com>,
Steven Rostedt <rostedt@goodmis.org>
Cc: "Eric Biederman" <ebiederm@xmission.com>,
"David Gow" <davidgow@google.com>,
"Alexey Dobriyan" <adobriyan@gmail.com>,
"Magnus Groß" <magnus.gross@rwth-aachen.de>,
kunit-dev@googlegroups.com, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH] binfmt_elf: Introduce KUnit test
Date: Wed, 23 Feb 2022 22:13:25 -0800 [thread overview]
Message-ID: <202202232208.B416701@keescook> (raw)
In-Reply-To: <CAGS_qxp8cjG5jCX-7ziqHcy2gq_MqL8kU01-joFD_W9iPG08EA@mail.gmail.com>
On Wed, Feb 23, 2022 at 10:07:04PM -0800, Daniel Latypov wrote:
> On Wed, Feb 23, 2022 at 9:43 PM Kees Cook <keescook@chromium.org> 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").
> >
> > Cc: Eric Biederman <ebiederm@xmission.com>
> > Cc: David Gow <davidgow@google.com>
> > Cc: Alexey Dobriyan <adobriyan@gmail.com>
> > Cc: "Magnus Groß" <magnus.gross@rwth-aachen.de>
> > Cc: kunit-dev@googlegroups.com
> > Cc: linux-fsdevel@vger.kernel.org
> > Signed-off-by: Kees Cook <keescook@chromium.org>
> > ---
> > I'm exploring ways to mock copy_to_user() for more tests in here.
> > kprobes doesn't seem to let me easily hijack a function...
>
> Yeah, there doesn't seem to be a good way to do so. It seems more
> feasible if one is willing to write arch-specific code, but I'm not
> quite sure if that works either.
Yeah, I'm hoping maybe Steven has some ideas.
Steven, I want to do fancy live-patch kind or things to replace functions,
but it doesn't need to be particularly fancy because KUnit tests (usually)
run single-threaded, etc. It looks like kprobes could almost do it, but
I don't see a way to have it _avoid_ making a function call.
> https://kunit.dev/mocking.html has some thoughts on this.
> Not sure if there's anything there that would be useful to you, but
> perhaps it can give you some ideas.
Yeah, I figure a small refactoring to use a passed task_struct can avoid
the "current" uses in load_elf_binary(), etc, but the copy_to_user() is
more of a problem. I have considered inverting the Makefile logic,
though, and having binfmt_elf_test.c include binfmt_elf.c and have it
just use a #define to redirect copy_to_user, kind of how all the compat
handling is already done. But it'd be nice to have a "cleaner" mocking
solution...
>
> > ---
> > fs/Kconfig.binfmt | 17 +++++++++++
> > fs/binfmt_elf.c | 4 +++
> > fs/binfmt_elf_test.c | 64 ++++++++++++++++++++++++++++++++++++++++++
> > fs/compat_binfmt_elf.c | 2 ++
> > 4 files changed, 87 insertions(+)
> > create mode 100644 fs/binfmt_elf_test.c
> >
> > diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt
> > index 4d5ae61580aa..8e14589ee9cc 100644
> > --- a/fs/Kconfig.binfmt
> > +++ b/fs/Kconfig.binfmt
> > @@ -28,6 +28,23 @@ config BINFMT_ELF
> > ld.so (check the file <file:Documentation/Changes> for location and
> > latest version).
> >
> > +config BINFMT_ELF_KUNIT_TEST
> > + bool "Build KUnit tests for ELF binary support" if !KUNIT_ALL_TESTS
> > + depends on KUNIT=y && BINFMT_ELF=y
> > + default KUNIT_ALL_TESTS
> > + help
> > + This builds the ELF loader KUnit tests.
> > +
> > + KUnit tests run during boot and output the results to the debug log
> > + in TAP format (https://testanything.org/). Only useful for kernel devs
>
> Tangent: should we update the kunit style guide to not refer to TAP
> anymore as it's not accurate?
> The KTAP spec is live on kernel.org at
> https://www.kernel.org/doc/html/latest/dev-tools/ktap.html
>
> We can leave this patch as-is and update later, or have it be the
> guinea pig for the new proposed wording.
Oops, good point. I was actually thinking it doesn't make too much sense
to keep repeating the same long boilerplate generally.
> (I'm personally in favor of people not copy-pasting these paragraphs
> in the first place, but that is what the style-guide currently
> recommends)
Let's change the guide? :)
>
> > + running KUnit test harness and are not for inclusion into a
> > + production build.
> > +
> > + For more information on KUnit and unit tests in general please refer
> > + to the KUnit documentation in Documentation/dev-tools/kunit/.
> > +
> > + If unsure, say N.
> > +
> > config COMPAT_BINFMT_ELF
> > def_bool y
> > depends on COMPAT && BINFMT_ELF
> > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> > index 76ff2af15ba5..9bea703ed1c2 100644
> > --- a/fs/binfmt_elf.c
> > +++ b/fs/binfmt_elf.c
> > @@ -2335,3 +2335,7 @@ static void __exit exit_elf_binfmt(void)
> > core_initcall(init_elf_binfmt);
> > module_exit(exit_elf_binfmt);
> > MODULE_LICENSE("GPL");
> > +
> > +#ifdef CONFIG_BINFMT_ELF_KUNIT_TEST
> > +#include "binfmt_elf_test.c"
> > +#endif
> > diff --git a/fs/binfmt_elf_test.c b/fs/binfmt_elf_test.c
> > new file mode 100644
> > index 000000000000..486ad419f763
> > --- /dev/null
> > +++ b/fs/binfmt_elf_test.c
> > @@ -0,0 +1,64 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +#include <kunit/test.h>
> > +
> > +static void total_mapping_size_test(struct kunit *test)
> > +{
> > + struct elf_phdr empty[] = {
> > + { .p_type = PT_LOAD, .p_vaddr = 0, .p_memsz = 0, },
> > + { .p_type = PT_INTERP, .p_vaddr = 10, .p_memsz = 999999, },
> > + };
> > + /*
> > + * readelf -lW /bin/mount | grep '^ .*0x0' | awk '{print "\t\t{ .p_type = PT_" \
> > + * $1 ", .p_vaddr = " $3 ", .p_memsz = " $6 ", },"}'
> > + */
> > + struct elf_phdr mount[] = {
> > + { .p_type = PT_PHDR, .p_vaddr = 0x00000040, .p_memsz = 0x0002d8, },
> > + { .p_type = PT_INTERP, .p_vaddr = 0x00000318, .p_memsz = 0x00001c, },
> > + { .p_type = PT_LOAD, .p_vaddr = 0x00000000, .p_memsz = 0x0033a8, },
> > + { .p_type = PT_LOAD, .p_vaddr = 0x00004000, .p_memsz = 0x005c91, },
> > + { .p_type = PT_LOAD, .p_vaddr = 0x0000a000, .p_memsz = 0x0022f8, },
> > + { .p_type = PT_LOAD, .p_vaddr = 0x0000d330, .p_memsz = 0x000d40, },
> > + { .p_type = PT_DYNAMIC, .p_vaddr = 0x0000d928, .p_memsz = 0x000200, },
> > + { .p_type = PT_NOTE, .p_vaddr = 0x00000338, .p_memsz = 0x000030, },
> > + { .p_type = PT_NOTE, .p_vaddr = 0x00000368, .p_memsz = 0x000044, },
> > + { .p_type = PT_GNU_PROPERTY, .p_vaddr = 0x00000338, .p_memsz = 0x000030, },
> > + { .p_type = PT_GNU_EH_FRAME, .p_vaddr = 0x0000b490, .p_memsz = 0x0001ec, },
> > + { .p_type = PT_GNU_STACK, .p_vaddr = 0x00000000, .p_memsz = 0x000000, },
> > + { .p_type = PT_GNU_RELRO, .p_vaddr = 0x0000d330, .p_memsz = 0x000cd0, },
> > + };
> > + size_t mount_size = 0xE070;
> > + /* https://lore.kernel.org/lkml/YfF18Dy85mCntXrx@fractal.localdomain */
>
> Slight nit, it looks like that message wasn't sent to lkml.
> lore gives a suggestion to change to
> https://lore.kernel.org/linux-fsdevel/YfF18Dy85mCntXrx@fractal.localdomain/
Ah, thank you. I was replacing the /r/ that used to be in that URL, and
got lost. :)
--
Kees Cook
next prev parent reply other threads:[~2022-02-24 6:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-24 5:43 [PATCH] binfmt_elf: Introduce KUnit test Kees Cook
2022-02-24 6:07 ` Daniel Latypov
2022-02-24 6:13 ` Kees Cook [this message]
2022-02-24 7:57 ` David Gow
2022-02-24 14:15 ` Steven Rostedt
2022-03-01 1:48 ` Daniel Latypov
2022-03-01 3:17 ` Kees Cook
2022-03-01 4:21 ` Steven Rostedt
2022-03-01 6:42 ` Daniel Latypov
2022-03-01 15:06 ` Steven Rostedt
2022-02-24 7:41 ` David Gow
2022-02-24 9:45 ` Alexey Dobriyan
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=202202232208.B416701@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=rostedt@goodmis.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.