Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp227657iob; Mon, 2 May 2022 17:50:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwiIiQtg8stnilqLl69W+Ji00bBpGNRLysR2raMMyx7RnY2RU0mCetEMSYJgUtyuESle+tF X-Received: by 2002:a63:2b8b:0:b0:3c1:f789:4d19 with SMTP id r133-20020a632b8b000000b003c1f7894d19mr8419609pgr.522.1651539023116; Mon, 02 May 2022 17:50:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651539023; cv=none; d=google.com; s=arc-20160816; b=YlEYoQaGp25FQoDZJe2t1mfX/R7We1Rle4RVR9MZz2VMjQw18fJfZ3wLyQweMLX5Zb ygakdUU5+Bwy7r3aG4ybK/JFje6kZIQxZN4/VhzVWq0FL1TkMkvSx14u0ZjrxbPqigh1 syIv1li40I5gY+w+RGDyxlFtnLKCa7QFuOOGs6yNhNKnAYF+YHVfDEr9dnc9X0UH9+O8 zjqmShKJ+l91XQHTCI6yC2xiyXAORu7SEgn5WYTI5Vh3KQW2YznMppcKkiDFQ7Lty3Qg 5fXAvzE9YivzE+L1M6sybhmzGkk4beQvfZ48M73RSf7rnsCHKLdUf+z1tpOWDr3MSqgp GeJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=FsxRG+o5tCFQ9J2x/QjS5qnwU7KinLZIjT5m8zCRNvI=; b=oNEOXZkZ4a3irHEPbUChL3p3GX/N8P5a2ZrrIIXahEIe643C8CiZedQlR/DIKuixgd GY15oP36FdqurfFYrUIyqxXC7wK/9Hem/JFO4Q/S36ytG0p5YqcvwV2ZNOeJFa6ZbX9Q hfthW475Hh70qwDxPQ5FhoVjB3EVjN5uACK4O9ZTGnkIKBX1+XLEcHoGoF4jgdkD+goF IuzLP/faI7Kl6dJX2y7VyrvQJO2j4S8+u6GFSivplTmPyTUxOpkzVlxP3NWrsPr0Gw02 7CCn8DQK/BPHCXRtll1bwJRryZsqkbiQAfjugpj9qScd3giyoyOL2sDszKWhO48DdnLI K09w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=iglSFNTl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id j5-20020a170902758500b00158b6f04ad1si14600388pll.192.2022.05.02.17.50.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 May 2022 17:50:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=iglSFNTl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0A87939807; Mon, 2 May 2022 17:38:10 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347642AbiEAS0Z (ORCPT + 99 others); Sun, 1 May 2022 14:26:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55592 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356465AbiEAS0V (ORCPT ); Sun, 1 May 2022 14:26:21 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:e::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0195956F90; Sun, 1 May 2022 11:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=FsxRG+o5tCFQ9J2x/QjS5qnwU7KinLZIjT5m8zCRNvI=; b=iglSFNTl8xU8y6sJPUcWiF+8zA nFZr9469FlwEN2Q04GrInbny8Sk1c7BqVTRdk7FJEwOx4Yi4RLsmUeN3T2xRXTw5AUzSDcQIQdLvf CkxZwTnLDq7e2AlYl1dzNkIkNSIXVukLMcaeMR7/+m6matsNwqp8fXt/tLUoTm4OIC4gi/EkTvoo/ dHJarYVn7yhFAbklYOsOpArsiFe2R5flgRyHTaNX7J4EZPEg3AaTfPu3k6dzjecDWzrpcJmtErwua vDAuzP+yTIOW/SEf9/63Fmd9fEVhXeUyJLUZM5GOrsmVwlFMEW1vBYAzIWuqmlE/kBO/i4P8lNzxN Vz+uQJmg==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nlEDO-00Gh3W-4i; Sun, 01 May 2022 18:22:38 +0000 Date: Sun, 1 May 2022 11:22:38 -0700 From: Luis Chamberlain To: David Gow , Shuah Khan , Lucas De Marchi , Aaron Tomlin Cc: Brendan Higgins , Andy Shevchenko , Jonathan Corbet , Andrew Morton , Kees Cook , Shuah Khan , Greg KH , "Guilherme G . Piccoli" , 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, Jani Nikula Subject: Re: [PATCH v2] kunit: Taint kernel if any tests run Message-ID: References: <20220429043913.626647-1-davidgow@google.com> <20220430030019.803481-1-davidgow@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220430030019.803481-1-davidgow@google.com> Sender: Luis Chamberlain X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE autolearn=no 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 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 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