linux-kernel - Re: [PATCH v3 2/3] kunit: Taint the kernel when KUnit tests are run

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 17 May 2022 16:58:09 -0400
From:   Brendan Higgins <brendanhiggins@...gle.com>
To:     Daniel Latypov <dlatypov@...gle.com>
Cc:     David Gow <davidgow@...gle.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Jonathan Corbet <corbet@....net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Kees Cook <keescook@...omium.org>,
        Shuah Khan <skhan@...uxfoundation.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Luis Chamberlain <mcgrof@...nel.org>,
        "Guilherme G . Piccoli" <gpiccoli@...lia.com>,
        Sebastian Reichel <sre@...nel.org>,
        John Ogness <john.ogness@...utronix.de>,
        Joe Fradley <joefradley@...gle.com>,
        KUnit Development <kunit-dev@...glegroups.com>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        Lucas De Marchi <lucas.demarchi@...el.com>,
        Aaron Tomlin <atomlin@...hat.com>,
        linux-fsdevel@...r.kernel.org, linux-block@...r.kernel.org
Subject: Re: [PATCH v3 2/3] kunit: Taint the kernel when KUnit tests are run

On Sat, May 14, 2022 at 3:25 PM Daniel Latypov <dlatypov@...gle.com> wrote:
>
> On Fri, May 13, 2022 at 8:04 PM David Gow <davidgow@...gle.com> wrote:
> > Hmm... thinking about it, I think it might be worth not tainting if 0
> > suites run, but tainting if 0 tests run.
> >
> > If we taint even if there are no suites present, that'll make things
> > awkward for the "build KUnit in, but not any tests" case: the kernel
> > would be tainted regardless. Given Android might be having the KUnit
>
> Actually, this is what the code does right now. I was wrong.
> If there are 0 suites => not tainted.
> If there are 0 tests in the suites => tainted.
>
> For kunit being built in, it first goes through this func
>    206  static void kunit_exec_run_tests(struct suite_set *suite_set)
>    207  {
>    208          struct kunit_suite * const * const *suites;
>    209
>    210          kunit_print_tap_header(suite_set);
>    211
>    212          for (suites = suite_set->start; suites <
> suite_set->end; suites++)
>    213                  __kunit_test_suites_init(*suites);
>    214  }
>
> So for the "build KUnit in, but not any tests" case, you'll never
> enter that for-loop.
> Thus you'll never call __kunit_test_suites_init() => kunit_run_tests().
>
> For module-based tests, we have the same behavior.
> If there's 0 test suites, we never enter the second loop, so we never taint.
> But if there's >0 suites, then we will, regardless of the # of test cases.
>
>    570  int __kunit_test_suites_init(struct kunit_suite * const * const suites)
>    571  {
>    572          unsigned int i;
>    573
>    574          for (i = 0; suites[i] != NULL; i++) {
>    575                  kunit_init_suite(suites[i]);
>    576                  kunit_run_tests(suites[i]);
>    577          }
>    578          return 0;
>    579  }
>
> So this change should already work as intended.
>
> > execution stuff built-in (but using modules for tests), it's probably
> > worth not tainting there. (Though I think they have a separate way of
> > disabling KUnit as well, so it's probably not a complete
> > deal-breaker).
> >
> > The case of having suites but no tests should still taint the kernel,
> > as suite_init functions could still run.
>
> Yes, suite_init functions are the concern. I agree we should taint if
> there are >0 suites but 0 test cases.
>
> I don't think it's worth trying to be fancy and tainting iff there >0
> test cases or a suite_init/exit function ran.
>
> >
> > Assuming that seems sensible, I'll send out a v4 with that changed.
>
> Just to be clear: that shouldn't be necessary.

Agreed. I think the current behavior is acceptable, and should be
unobtrusive to Android: Joe has a patch that introduces a kernel param
which disables running KUnit tests at the suite level which would
happen before this taint occurs. So the only way the taint happens is
if we actually try to execute some test cases (whether or not the
cases actually run).

> > > I wasn't quite sure where this applied, but I manually applied the changes here.
> > > Without this patch, this command exits fine:
> > > $ ./tools/testing/kunit/kunit.py run --kernel_args=panic_on_taint=0x40000
> > >
> > > With it, I get
> > > [12:03:31] Kernel panic - not syncing: panic_on_taint set ...
> > > [12:03:31] CPU: 0 PID: 1 Comm: swapper Tainted: G                 N
> >
> > This is showing both 'G' and 'N' ('G' being the character for GPL --
>
> I just somehow missed the fact there was an 'N' at the end there.
> Thanks, I thought I was going crazy. I guess I was just going blind.
>
>
> Daniel