From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CD2F0C433FE for ; Sat, 14 May 2022 03:04:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230336AbiENDEq (ORCPT ); Fri, 13 May 2022 23:04:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60636 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230200AbiENDEp (ORCPT ); Fri, 13 May 2022 23:04:45 -0400 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A59B32E07FD for ; Fri, 13 May 2022 20:04:40 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id q20so5695938wmq.1 for ; Fri, 13 May 2022 20:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UoAT8pjpOFcRyIaX+ZhbsdRFzNEAyY56dcHcgCnxySo=; b=edjiyqrDP2iLrGQci5HqJboHVDFmTJ/F0cVt2hEhqmcmZ1Bk3naqPevsH50aZD4bgL uBgAhlV9Rj0RBJ56NenEvJKuGc6772MbvBrXXNbzVOP+EC1sBTEu+10lN8/8axj7fG1N vk97VTRaDsfr5aMeV0pBT5JNUKtnKH5L6QaFyXYcbvuHq5NHIerSyN4yyEtubLhbHgUj IIBX/JBXVmbeHvA8pLO/5tUmzYZ2pkRoQwfskzITXr4dHOmkfxhcL42inxRIGVbqhEe7 iQc1vYNPhvt+x0PWly/ZBGnxlxc2VJ/wpp56ADg9gnyrloSquEsApgEvgYEUFNnORcv/ Ll4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UoAT8pjpOFcRyIaX+ZhbsdRFzNEAyY56dcHcgCnxySo=; b=ZrzA7sOxbd4Ph6WMLM/yLcHbY1IVCMp8et6kyMKOkMi+NMviVHDQHRLlosavXRkVRL 78nCfWCrbOxBYtz6Nz5/7NZd9E1XfnDX/ap6Nd8mYeRlXPboQ/jaYD8pXOkRpro12pSg lynYCs1Bf/MDYZVphD7wfmSZR5IK7d7I/DKNjTCn8MyIMA0fdXR53G+QbBbzmT8p7Pes 1HtvgpGzFjYa2FyWbnlmJZkLgnn0WpcarlKUz6KfjPxXODdvqyuEGOtkO1elJd+SUZR1 IvZt0TRopG/t9JzKU3mW6akrANgdYIqwgVheNImG/K/7IEO2GzbzJ5T8QX6XoWaxj/S+ smDw== X-Gm-Message-State: AOAM532KLwOPmW0KNIO2ts2/cDySuOx5477Jz/Da/d28moVFiMSGvTr9 UT/wzQGwl3zJu2wf7gJl6FL5Cs+qus2PoAOTUK7UyQ== X-Google-Smtp-Source: ABdhPJyqMTuCvPq2xupVijryWNy90M9KW5CbLPjYdKU/0lgqe+OXIfvdq3TgEH84h6n59TOZr0qbmIWNpw3XU3CMz+w= X-Received: by 2002:a05:600c:264e:b0:394:2c56:eeb5 with SMTP id 14-20020a05600c264e00b003942c56eeb5mr7208280wmy.6.1652497479045; Fri, 13 May 2022 20:04:39 -0700 (PDT) MIME-Version: 1.0 References: <20220429043913.626647-1-davidgow@google.com> <20220513083212.3537869-2-davidgow@google.com> In-Reply-To: From: David Gow Date: Sat, 14 May 2022 11:04:27 +0800 Message-ID: Subject: Re: [PATCH v3 2/3] kunit: Taint the kernel when KUnit tests are run To: Daniel Latypov Cc: Brendan Higgins , Andy Shevchenko , Jonathan Corbet , Andrew Morton , Kees Cook , Shuah Khan , Greg KH , Luis Chamberlain , "Guilherme G . Piccoli" , Sebastian Reichel , John Ogness , Joe Fradley , KUnit Development , "open list:KERNEL SELFTEST FRAMEWORK" , "open list:DOCUMENTATION" , Linux Kernel Mailing List , Jani Nikula , Lucas De Marchi , Aaron Tomlin , linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Sat, May 14, 2022 at 3:09 AM Daniel Latypov wrote: > > On Fri, May 13, 2022 at 1:32 AM David Gow wrote: > > > > Make KUnit trigger the new TAINT_TEST taint when any KUnit test is run. > > Due to KUnit tests not being intended to run on production systems, and > > potentially causing problems (or security issues like leaking kernel > > addresses), the kernel's state should not be considered safe for > > production use after KUnit tests are run. > > > > Signed-off-by: David Gow > > Tested-by: Daniel Latypov > > Looks good to me. > > There's an edge case where we might have 0 suites or 0 tests and we > still taint the kernel, but I don't think we need to deal with that. > At the start of kunit_run_tests() is the cleanest place to do this. Hmm... thinking about it, I think it might be worth not tainting if 0 suites run, but tainting if 0 tests run. If we taint even if there are no suites present, that'll make things awkward for the "build KUnit in, but not any tests" case: the kernel would be tainted regardless. Given Android might be having the KUnit execution stuff built-in (but using modules for tests), it's probably worth not tainting there. (Though I think they have a separate way of disabling KUnit as well, so it's probably not a complete deal-breaker). The case of having suites but no tests should still taint the kernel, as suite_init functions could still run. Assuming that seems sensible, I'll send out a v4 with that changed. > I wasn't quite sure where this applied, but I manually applied the changes here. > Without this patch, this command exits fine: > $ ./tools/testing/kunit/kunit.py run --kernel_args=panic_on_taint=0x40000 > > With it, I get > [12:03:31] Kernel panic - not syncing: panic_on_taint set ... > [12:03:31] CPU: 0 PID: 1 Comm: swapper Tainted: G N This is showing both 'G' and 'N' ('G' being the character for GPL -- i.e. the kernel is not tainted by proprietary modules: 'P'). Jani did suggest a better way of printing these in the v1 discussion (printing the actual names of taints present), which I might do in a follow-up. > 5.17.0-00001-gea9ee5e7aed8-dirty #60 > > I'm a bit surprised that it prints 'G' and not 'N', but this does seem > to be the right mask > $ python3 -c 'print(hex(1<<18))' > 0x40000 > and it only takes effect when this patch is applied. > I'll chalk that up to my ignorance of how taint works. -- David