Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp2492616iob; Sat, 30 Apr 2022 10:00:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxPx/X2O6zsv6g5reS+RIyOs81i41HjC0ZbPp2iFwG6mOc0EHnIiqtTYsGuQ08PsZNZToFG X-Received: by 2002:a05:6512:3f8c:b0:45d:cb2a:8779 with SMTP id x12-20020a0565123f8c00b0045dcb2a8779mr3601194lfa.499.1651338007999; Sat, 30 Apr 2022 10:00:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651338007; cv=none; d=google.com; s=arc-20160816; b=tcHXN1fjre1UgrXWkrVgW3gDifZ7j1SiLpCxYjwb6XhU7x18MxvPFjqW8jnuc52DSK JqBLo55HFdF3rlz/L1dYqWcX7h1221WkeCe4FWq4vmmHXieS0K1Q72gEuG5LKNNDZX21 YPiS8p1kBlDjX8psAEAKwVT56pfhuJaxvw1FOC5hdEjjNo45JKyqIyPr3c7FPPCDBLR/ jq4AUXEnnHsOODN1nK4Io4JDQzrAPm/t/BmiGtp0FUriHta2xcUunnSklI2fIqh7zXvl n0/02qgtThcb0yjyNNzU1j8EILbigTzcN1vuZNcDoJNKvmlh54aQla1Z1FrZRzo10pZq a2iQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :organization:in-reply-to:subject:cc:to:from:dkim-signature; bh=c+duBjROhSLWvLLn7XyjSEwDYKIpOquGiCbIKIxBrr4=; b=mT+sz35O7kxBd5GsV2K3C2+/ba3S0+4VWWjRV82GfyNDNJQAFp4rBQURIyxsZcwfV7 orQOPmsK0OYV9Rsk9HxUXXJLgqyvXMurE3GXpQA5TbBCmhFoiyXJE5/pNs1xY3YQ/nyV 3B/h2furXR2wNUXcabkfZY4SLUDilqwPrVNtRjCWtFHnS59Nr9hh1H63Lk76aPr7qnlQ ZkR1nK/R99Eg3UBQ951AGPu0R4AQSM71riBQVzAVHCjDLnEit1jHCX5uJq1bMiWyhD2C QCoGkX8fJyPs952byh3SIG62dt3HP4gKCSk79Gy+LUNTA4C5ym83Wp/qPnbZtA5lka2k LKWw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=JtFmQrsS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u9-20020a05651206c900b00449fff282acsi10325914lff.558.2022.04.30.09.59.34; Sat, 30 Apr 2022 10:00:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=JtFmQrsS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358272AbiD2L1t (ORCPT + 99 others); Fri, 29 Apr 2022 07:27:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49128 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345528AbiD2L1r (ORCPT ); Fri, 29 Apr 2022 07:27:47 -0400 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BDD5632ECF; Fri, 29 Apr 2022 04:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1651231469; x=1682767469; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=lb5yLVgnVmkYIIVoioX0WLdSXH8dIeW5esUM9LN0+Yw=; b=JtFmQrsSBvjGoMstEdpTgLP8vLj4ghxj61X0Sg9bTsXUp21izRTEzKQG Y6zVur5olhoKo1TswzYpCusMf1aKNE6PoQusgsNn/QX7NERlzFJoUu4k/ 7XD/8bf/TrXbV92ukwW4ingwZ+YesOkj8K7gEn6h7MP1joHVeuuoAqTeM X7/Rv5e/jIlFguNGiLLVflB+WI0qUxXsvydbQtAdNQru3LFYbNmXpXsCr ysgcPGY27SpCxC4YOfQr5AfMsw49B4tCxgE4VfQS8ubCjU8++rNnR1X8P Jvxg1IfQ/KdBmO3+uzKWD8eZr1a73mKG9/xX20NE+FCsslVW2RJE5c6ja Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10331"; a="266144752" X-IronPort-AV: E=Sophos;i="5.91,185,1647327600"; d="scan'208";a="266144752" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Apr 2022 04:21:35 -0700 X-IronPort-AV: E=Sophos;i="5.91,185,1647327600"; d="scan'208";a="534437328" Received: from agerasym-mobl.ger.corp.intel.com (HELO localhost) ([10.249.133.25]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Apr 2022 04:21:29 -0700 From: Jani Nikula To: Greg KH , David Gow Cc: Brendan Higgins , Andy Shevchenko , Jonathan Corbet , Andrew Morton , Kees Cook , Shuah Khan , "Guilherme G . Piccoli" , Luis Chamberlain , Sebastian Reichel , John Ogness , Joe Fradley , Daniel Latypov , kunit-dev@googlegroups.com, linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] kunit: Taint kernel if any tests run In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20220429043913.626647-1-davidgow@google.com> Date: Fri, 29 Apr 2022 14:21:26 +0300 Message-ID: <87tuacrv7t.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 29 Apr 2022, Greg KH wrote: > On Fri, Apr 29, 2022 at 12:39:14PM +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 >> --- >> >> This is something I'd been thinking about for a while, and it came up >> again, so I'm finally giving it a go. >> >> Two notes: >> - I decided to add a new type of taint, as none of the existing ones >> really seemed to fit. We could live with considering KUnit tests as >> TAINT_WARN or TAINT_CRAP or something otherwise, but neither are quite >> right. >> - The taint_flags table gives a couple of checkpatch.pl errors around >> bracket placement. I've kept the new entry consistent with what's >> there rather than reformatting the whole table, but be prepared for >> complaints about spaces. >> >> Thoughts? >> -- David >> >> --- >> Documentation/admin-guide/tainted-kernels.rst | 1 + >> include/linux/panic.h | 3 ++- >> kernel/panic.c | 1 + >> lib/kunit/test.c | 4 ++++ >> 4 files changed, 8 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst >> index ceeed7b0798d..8f18fc4659d4 100644 >> --- a/Documentation/admin-guide/tainted-kernels.rst >> +++ b/Documentation/admin-guide/tainted-kernels.rst >> @@ -100,6 +100,7 @@ Bit Log Number Reason that got the kernel tainted >> 15 _/K 32768 kernel has been live patched >> 16 _/X 65536 auxiliary taint, defined for and used by distros >> 17 _/T 131072 kernel was built with the struct randomization plugin >> + 18 _/N 262144 a KUnit test has been run >> === === ====== ======================================================== >> >> Note: The character ``_`` is representing a blank in this table to make reading >> diff --git a/include/linux/panic.h b/include/linux/panic.h >> index f5844908a089..1d316c26bf27 100644 >> --- a/include/linux/panic.h >> +++ b/include/linux/panic.h >> @@ -74,7 +74,8 @@ static inline void set_arch_panic_timeout(int timeout, int arch_default_timeout) >> #define TAINT_LIVEPATCH 15 >> #define TAINT_AUX 16 >> #define TAINT_RANDSTRUCT 17 >> -#define TAINT_FLAGS_COUNT 18 >> +#define TAINT_KUNIT 18 >> +#define TAINT_FLAGS_COUNT 19 >> #define TAINT_FLAGS_MAX ((1UL << TAINT_FLAGS_COUNT) - 1) >> >> struct taint_flag { >> diff --git a/kernel/panic.c b/kernel/panic.c >> index eb4dfb932c85..b24ca63ed738 100644 >> --- a/kernel/panic.c >> +++ b/kernel/panic.c >> @@ -404,6 +404,7 @@ const struct taint_flag taint_flags[TAINT_FLAGS_COUNT] = { >> [ TAINT_LIVEPATCH ] = { 'K', ' ', true }, >> [ TAINT_AUX ] = { 'X', ' ', true }, >> [ TAINT_RANDSTRUCT ] = { 'T', ' ', true }, >> + [ TAINT_KUNIT ] = { 'N', ' ', false }, > > As kunit tests can be in modules, shouldn't this be "true" here? > > Overall, I like it, makes sense to me. The "N" will take some getting > used to, and I have no idea why "T" was for "struct randomization", that > would have allowed you to use "T" instead. Oh well. Would you consider a patch adding more self-explanatory taint flag strings to the output? BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center