On Tue, May 03, 2022 at 02:49:58PM +0800, David Gow wrote:
On Mon, May 2, 2022 at 2:24 AM Luis Chamberlain mcgrof@kernel.org wrote:
On Sun, May 01, 2022 at 11:22:38AM -0700, Luis Chamberlain wrote:
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@google.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.
My initial thought is that KUnit is explicitly in-kernel testing, whereas kselftest is (at least somewhat) user-space based.
selftests has modules, although I am not sure if there are selftests which do not load modules. Shuah?
My personal feeling is that "doing weird stuff from userspace" is fundamentally different from "doing weird stuff in the kernel".
True.
That being said, in practice many kselftest tests load modules which do strange things, and those could be in scope for something like that. I'd still err on the side of only having those tests (or specifically those modules) add the taint, rather than all selftests, but could be conveniced.
Yeah I think now that this can easily be added by having a special new module info, MODULE_TAINTS(taint_flag). Then in check_modinfo() you'd get_modinfo(info, "taints") to then add_taint_module() if set.
We can ignore the userspace thing I mentioned earlier as I thought at first we could not add the taint to selftest modules easily but we can.
Luis