Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp73140pxb; Mon, 8 Feb 2021 15:40:08 -0800 (PST) X-Google-Smtp-Source: ABdhPJyBOzEf4K2hh0CfIAv4JPedunqM+wZ/CDkBcbdniQ1ZZA7PODIjqK21WePXEg4cOZ2VHQga X-Received: by 2002:a17:907:3f13:: with SMTP id hq19mr19561369ejc.142.1612827608718; Mon, 08 Feb 2021 15:40:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612827608; cv=none; d=google.com; s=arc-20160816; b=cQLITmM8vkFv9gp/+AILfYTA6nYvT4gXp/FUKBGC+VS9lSdCPg82LGTasX5lv7pB5J 0V6N8QkfyR2NGE/7hcGH469+TdeQ9k0LbejLHyBUzwdfkulgxbDL2jbHugQQt8wq3yRj 4TrR5lHdmSYq2Bs58H1w92DbZObVn+hr0vm1ub43ggU9xmff1Go6G9WgxUgojEQ5iFQX Ce1ZmjV2CmB3Y0/Rcp3d0m87zdKE7ljq/lF7gJkSupx8gXN3Afa6sGVzjz/sMZE2M7k7 MZczt7cNBrLZJ7dPMzvIg98VKTEkv53fGbh7aA3v980XCHoFhfKzoUY2Q2nxELcd4rJs GOfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=eGGcKAyTzmY7XmHqKjg37Fb2afx54tMCqzIlqIxaU7M=; b=vNQCZnBjN8b3GFXNQyS3TAZq7enyEqXcaLIfQBnS9GcwSCS9zHun9NYTmRfWiI7z0y O9cSkpsRqMkcBIf1xKZU9mpYSbtNiYIF5RLfX6jO582aIGgZwtXA6LT85eSqCIubZkKZ K4bNHskflnWTQwE1xZquYvVXL1WkamDQd0m/k2ISiweUdQk17NvpzGxKPqZr+9LvFkgv dFXp2QE/ScN6qDLV6Y3qAizpzI74lokBvUTGvv5kxRaO/7smtQJ346WAgdRHIUgVmkk4 z+iW8NL6YnzYfWqWL6jWepxRyRLje0uW7oGCZLiImXaRhFAl4aWQGo8FZUHeXpOB3rl4 QTCg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=E5dDhWEL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y6si10671380eju.9.2021.02.08.15.39.45; Mon, 08 Feb 2021 15:40:08 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=E5dDhWEL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231366AbhBHXhm (ORCPT + 99 others); Mon, 8 Feb 2021 18:37:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47624 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229822AbhBHXh3 (ORCPT ); Mon, 8 Feb 2021 18:37:29 -0500 Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8EE3BC061788 for ; Mon, 8 Feb 2021 15:36:49 -0800 (PST) Received: by mail-ed1-x530.google.com with SMTP id df22so21328257edb.1 for ; Mon, 08 Feb 2021 15:36:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eGGcKAyTzmY7XmHqKjg37Fb2afx54tMCqzIlqIxaU7M=; b=E5dDhWELy3490cipw2qXqX2bxpHoPiVzQRaR2X4dSFiRqOjLee56yC4S848SYQ7DHE TdW2iX6wSAayi8M7TQ5MMi4LhfUPROW4AZ6ZZOqjJFTYTE5q5E4sV/GibnBSH8lySu0y Uyvf6SQAxXS7uRrtKj3agOmXXQYr2c5xv+HgO5WxwAvRmw/+0NiQSSyWhVntPGknaeyA 2q042JtRZZZYrxE5qrQYldeSgOlG0x2U0IaHs3AwcLCd7L5nOVh3ATxC4Zkpls71QW8X iF7cHXO4b5hDGaLJSd8+KCt2uoywgyj2XpoqdNsGqaqAxuWIKViVqb100OOjUtUyje0Z k2DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eGGcKAyTzmY7XmHqKjg37Fb2afx54tMCqzIlqIxaU7M=; b=uXKO/yospdqmEfPpCbLiForvAhpSIX2HZVAetxQEgybqtQGj8IF+VpxmJ1ZTskwgWB LHe0rMCcjC6BQ4XEq53VeJKBQNYX1RKyctVTOltuoZsrY0a5DEmsq60Bp4cjptfzS+P9 3Ly3iB5HR2i6vRX4WlSue0D5+u5RQUYDtc0/cjoJ4UypWNPfwX8V21utoKYS8jIP+P/7 1kjhCYL4ZjQ7m6f9LyWC3xv8rJdBpk4Qpbz95tzQEBamNeOMOv6RRMSlzFztbz7DG92i 44qOPNqqualHkk6Y8CdZDu7fnQ9V47z6FTDGRX2cONuSOC09MWQH8TdV0AhVNNU9WEzS V9HA== X-Gm-Message-State: AOAM531/h9MYs0po4BRJboGReFQgkrHsPNzGq7qfKYL8iDu3p7YQtEVq LC7sKnRmp6ZvdOX3zrM36WptlW1ql8DygnX8GdDYnQ== X-Received: by 2002:aa7:cd87:: with SMTP id x7mr20441251edv.210.1612827408336; Mon, 08 Feb 2021 15:36:48 -0800 (PST) MIME-Version: 1.0 References: <20210130002438.1872527-1-ben.widawsky@intel.com> <20210130002438.1872527-9-ben.widawsky@intel.com> <202102081406.CDE33FB8@keescook> In-Reply-To: <202102081406.CDE33FB8@keescook> From: Dan Williams Date: Mon, 8 Feb 2021 15:36:35 -0800 Message-ID: Subject: Re: [PATCH 08/14] taint: add taint for direct hardware access To: Kees Cook Cc: Jonathan Corbet , linux-cxl@vger.kernel.org, Ben Widawsky , Linux ACPI , Linux Kernel Mailing List , linux-nvdimm , Linux PCI , Bjorn Helgaas , Chris Browy , Ira Weiny , Jon Masters , Jonathan Cameron , Rafael Wysocki , Randy Dunlap , Vishal Verma , daniel.lll@alibaba-inc.com, "John Groves (jgroves)" , "Kelley, Sean V" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 8, 2021 at 2:09 PM Kees Cook wrote: > > On Mon, Feb 08, 2021 at 02:00:33PM -0800, Dan Williams wrote: > > [ add Jon Corbet as I'd expect him to be Cc'd on anything that > > generically touches Documentation/ like this, and add Kees as the last > > person who added a taint (tag you're it) ] > > > > Jon, Kees, are either of you willing to ack this concept? > > > > Top-posting to add more context for the below: > > > > This taint is proposed because it has implications for > > CONFIG_LOCK_DOWN_KERNEL among other things. These CXL devices > > implement memory like DDR would, but unlike DDR there are > > administrative / configuration commands that demand kernel > > coordination before they can be sent. The posture taken with this > > taint is "guilty until proven innocent" for commands that have yet to > > be explicitly allowed by the driver. This is different than NVME for > > example where an errant vendor-defined command could destroy data on > > the device, but there is no wider threat to system integrity. The > > taint allows a pressure release valve for any and all commands to be > > sent, but flagged with WARN_TAINT_ONCE if the driver has not > > explicitly enabled it on an allowed list of known-good / kernel > > coordinated commands. > > > > On Fri, Jan 29, 2021 at 4:25 PM Ben Widawsky wrote: > > > > > > For drivers that moderate access to the underlying hardware it is > > > sometimes desirable to allow userspace to bypass restrictions. Once > > > userspace has done this, the driver can no longer guarantee the sanctity > > > of either the OS or the hardware. When in this state, it is helpful for > > > kernel developers to be made aware (via this taint flag) of this fact > > > for subsequent bug reports. > > > > > > Example usage: > > > - Hardware xyzzy accepts 2 commands, waldo and fred. > > > - The xyzzy driver provides an interface for using waldo, but not fred. > > > - quux is convinced they really need the fred command. > > > - xyzzy driver allows quux to frob hardware to initiate fred. > > > - kernel gets tainted. > > > - turns out fred command is borked, and scribbles over memory. > > > - developers laugh while closing quux's subsequent bug report. > > But a taint flag only lasts for the current boot. If this is a drive, it > could still be compromised after reboot. It sounds like this taint is > really only for ephemeral things? "vendor shenanigans" is a pretty giant > scope ... > That is true. This is more about preventing an ecosystem / cottage industry of tooling built around bypassing the kernel. So the kernel complains loudly and hopefully prevents vendor tooling from propagating and instead directs that development effort back to the native tooling. However for the rare "I know what I'm doing" cases, this tainted kernel bypass lets some experimentation and debug happen, but the kernel is transparent that when the capability ships in production it needs to be a native implementation. So it's less, "the system integrity is compromised" and more like "you're bypassing the development process that ensures sanity for CXL implementations that may take down a system if implemented incorrectly". For example, NVME reset is a non-invent, CXL reset can be like surprise removing DDR DIMM. Should this be more tightly scoped to CXL? I had hoped to use this in other places in LIBNVDIMM, but I'm ok to lose some generality for the specific concerns that make CXL devices different than other PCI endpoints.