Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp1447997iob; Fri, 29 Apr 2022 05:39:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx9rg+i7RhxiWFwwJTcl1OdKR6+XeeZ/xV4DMeo+fPACKd1OWUru4WWj7IdO6en2BhNYSL0 X-Received: by 2002:a05:6a00:b4e:b0:50d:a75a:ec6e with SMTP id p14-20020a056a000b4e00b0050da75aec6emr5112150pfo.19.1651235980606; Fri, 29 Apr 2022 05:39:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651235980; cv=none; d=google.com; s=arc-20160816; b=NyDQhoc2dEORQqIsaVMtFBVS90umSmF6I27YvuCMOtwJ2yiLqq7w9oC9MWYgQ37DU2 S/X2/Gc7gy1ush1tniaURD7Qr3ljBmkIJWaksnwbTLexVJmLwOz5rl8Z4rlZ8cRgiQ/n oHRyt7qKOBMtdqoOwtK2seuJOyAz5+cW2evJf6/HcLz/AHWp6fL2MMJeUqfZ1No/vGUL qUmUFSWnTtsRHHPYeShq0c2XFCsxs6hlJdkwJ8AYwqREEFBJ4hk++eoD0s5zy1Lo/HIN hOzT2OHU/H9TzcfCzCpSeQt8btSHVz435Htvh8PniwaiwOglCHt+t7Y/YYCeRxqfqYRN Bd7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=daDpAvKZ3djVCCelAPWZ++IB13cDlNG3UF7sYpN9HPM=; b=ZZrdvZ5QNgj8S1V/cugYOvboDOXo7Ss1AVfFTUK2jtt5nLBT6UWDVZyIFHTg+6PDRR igcprBx0B6/2DONjl2zcyvorK2BzAsBrL7rjkhq9rtIo6+iIjrTRt3AsmnTYhfGraYRa +/8gkBdeXdnoEhXnlJzOGGbLRQoHoGqhAtvFUkGnE723d9HPf44cyXpz0GepEZ69r93A apCed3kaan0utcXzCjUahtp0cXv7iJy+Ac0XSmhGC75fTRwGvo1ybU5gzEg0Xqnt+zIy W49SnpS3NM18xmjvDGX/Wu83ilQJKjtDkvuTbbD9PxuVd2W7V4sALoZiXg30vGnm0fll QfiQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=vUsW4BOx; 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=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s13-20020a170902b18d00b0015afeab2a56si6747476plr.69.2022.04.29.05.39.26; Fri, 29 Apr 2022 05:39:40 -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=@linuxfoundation.org header.s=korg header.b=vUsW4BOx; 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=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233241AbiD2Loq (ORCPT + 99 others); Fri, 29 Apr 2022 07:44:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59528 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239287AbiD2Lon (ORCPT ); Fri, 29 Apr 2022 07:44:43 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 96EEF6B088; Fri, 29 Apr 2022 04:41:24 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id EB25DCE3147; Fri, 29 Apr 2022 11:41:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6EE39C385A4; Fri, 29 Apr 2022 11:41:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1651232481; bh=P8ium3bEsenNU8fOZNp6SVKuLrL4nFiqeAGvhZZ70sM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=vUsW4BOxIR5pvn++nimGWwdRC8puiJd3L0G2l7shx5XlSrbbt/fLOm9KwCtVSHvbz WEI4w4erqu1GiNpS5POhXrHEp/DXDKv0ekJczHexhssYhZ522teJHFZjuDkSf3NUfq a6fdEGAdJvSGqHC6Cg4VZIACW3IyMIH1ntZNKpTQ= Date: Fri, 29 Apr 2022 13:41:17 +0200 From: Greg KH To: Jani Nikula Cc: David Gow , 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 Message-ID: References: <20220429043913.626647-1-davidgow@google.com> <87tuacrv7t.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87tuacrv7t.fsf@intel.com> X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS 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, Apr 29, 2022 at 02:21:26PM +0300, Jani Nikula wrote: > 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? Where would those strings go? In the oops report? Or somewhere else? thanks, greg k-h