lkml.org 
[lkml]   [2022]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v3 2/3] kunit: Taint the kernel when KUnit tests are run
    On Fri, May 13, 2022 at 1:32 AM David Gow <davidgow@google.com> wrote:
    >
    > Make KUnit trigger the new TAINT_TEST taint when any KUnit test is run.
    > Due to KUnit tests not being intended to run on production systems, and
    > potentially causing problems (or security issues like leaking kernel
    > addresses), the kernel's state should not be considered safe for
    > production use after KUnit tests are run.
    >
    > Signed-off-by: David Gow <davidgow@google.com>

    Tested-by: Daniel Latypov <dlatypov@google.com>

    Looks good to me.

    There's an edge case where we might have 0 suites or 0 tests and we
    still taint the kernel, but I don't think we need to deal with that.
    At the start of kunit_run_tests() is the cleanest place to do this.

    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
    5.17.0-00001-gea9ee5e7aed8-dirty #60

    I'm a bit surprised that it prints 'G' and not 'N', but this does seem
    to be the right mask
    $ python3 -c 'print(hex(1<<18))'
    0x40000
    and it only takes effect when this patch is applied.
    I'll chalk that up to my ignorance of how taint works.

    \
     
     \ /
      Last update: 2022-05-13 21:10    [W:4.069 / U:0.340 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site