linux-kernel - Re: [PATCH v2] kunit: Taint kernel if any tests 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]

Message-ID: <Ym7P7mCoMiQq99EM@bombadil.infradead.org>
Date:   Sun, 1 May 2022 11:22:38 -0700
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     David Gow <davidgow@...gle.com>,
        Shuah Khan <skhan@...uxfoundation.org>,
        Lucas De Marchi <lucas.demarchi@...el.com>,
        Aaron Tomlin <atomlin@...hat.com>
Cc:     Brendan Higgins <brendanhiggins@...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>,
        "Guilherme G . Piccoli" <gpiccoli@...lia.com>,
        Sebastian Reichel <sre@...nel.org>,
        John Ogness <john.ogness@...utronix.de>,
        Joe Fradley <joefradley@...gle.com>,
        Daniel Latypov <dlatypov@...gle.com>,
        kunit-dev@...glegroups.com, linux-kselftest@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        Jani Nikula <jani.nikula@...ux.intel.com>
Subject: Re: [PATCH v2] kunit: Taint kernel if any tests run

On Sat, Apr 30, 2022 at 11:00:19AM +0800, David Gow wrote:
> KUnit tests are not supposed to run on production systems: they may do
> deliberately illegal things to trigger errors, and have security
> implications (assertions will often deliberately leak kernel addresses).
> 
> Add a new taint type, TAINT_KUNIT to signal that a KUnit test has been
> run. This will be printed as 'N' (for kuNit, as K, U and T were already
> taken).
> 
> This should discourage people from running KUnit tests on production
> systems, and to make it easier to tell if tests have been run
> accidentally (by loading the wrong configuration, etc.)
> 
> Signed-off-by: David Gow <davidgow@...gle.com>

There is no reason to distinguish kunit from selftests if the result is
the same: really make the kernel try really insane stupid things which
may crash it or put it into a bad state.

So no, this should be renamed to "TEST_BREAK" as I think outside of
selftest and kunit we may grow the kernel to do stupid things outside
of that domain and this gives us the flexilibilty to use that in other
places as well.

It begs the question if we *should* allow userspace to volunterally say
"hey, we are doing really insane things, brace yourself." Why ? Well
because selftest has tons of modules. We either then define a macro
that adds the taint for them and wrap the module declaration for it,
or we expose a syctl to let userspace volunteer to opt-in to seggest
we are about to try something stupid with the kernel including loading
some dangeerous modules which may not have macros which taint the kernel.
That would let selftest taint on *any* selftest. Because we can run all
selftests or run one selftest.

Then, if such sysctl is exposed, maybe we should then also use this for
example for blktests, fstests, fio tests, etc.

  Luis