From: Daniel Latypov <dlatypov@google.com>
To: Kees Cook <keescook@chromium.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:07:04 -0800 [thread overview]
Message-ID: <CAGS_qxp8cjG5jCX-7ziqHcy2gq_MqL8kU01-joFD_W9iPG08EA@mail.gmail.com> (raw)
In-Reply-To: <20220224054332.1852813-1-keescook@chromium.org>
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.
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.
> ---
> 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.
(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)
> + 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/
next prev parent reply other threads:[~2022-02-24 6:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-24 5:43 Kees Cook
2022-02-24 6:07 ` Daniel Latypov [this message]
2022-02-24 6:13 ` Kees Cook
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=CAGS_qxp8cjG5jCX-7ziqHcy2gq_MqL8kU01-joFD_W9iPG08EA@mail.gmail.com \
--to=dlatypov@google.com \
--cc=adobriyan@gmail.com \
--cc=davidgow@google.com \
--cc=ebiederm@xmission.com \
--cc=keescook@chromium.org \
--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 \
/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