linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: iommu@lists.linux-foundation.org
Cc: Joerg Roedel <joro@8bytes.org>,
	David Woodhouse <dwmw2@infradead.org>,
	Lu Baolu <baolu.lu@linux.intel.com>,
	Ashok Raj <ashok.raj@intel.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Jacob jun Pan <jacob.jun.pan@intel.com>,
	Andreas Noever <andreas.noever@gmail.com>,
	Michael Jamet <michael.jamet@intel.com>,
	Yehezkel Bernat <YehezkelShB@gmail.com>,
	Lukas Wunner <lukas@wunner.de>,
	Christian Kellner <ckellner@redhat.com>,
	Mario.Limonciello@dell.com,
	Anthony Wong <anthony.wong@canonical.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH 4/4] thunderbolt: Export IOMMU based DMA protection support to userspace
Date: Mon, 12 Nov 2018 19:06:28 +0300	[thread overview]
Message-ID: <20181112160628.86620-5-mika.westerberg@linux.intel.com> (raw)
In-Reply-To: <20181112160628.86620-1-mika.westerberg@linux.intel.com>

Recent systems shipping with Windows 10 version 1803 or later may
support a feature called Kernel DMA protection [1]. In practice this
means that Thunderbolt connected devices are placed behind an IOMMU
during the whole time it is connected (including during boot) making
Thunderbolt security levels redundant. Some of these systems still have
Thunderbolt security level set to "user" in order to support OS
downgrade (the older version of the OS might not support IOMMU based DMA
protection so connecting a device still relies on user approval then).

Export this information to userspace by introducing a new sysfs
attribute (iommu_dma_protection). Based on it userspace tools can make
more accurate decision whether or not authorize the connected device.

In addition update Thunderbolt documentation regarding IOMMU based DMA
protection.

[1] https://docs.microsoft.com/en-us/windows/security/information-protection/kernel-dma-protection-for-thunderbolt

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
---
 .../ABI/testing/sysfs-bus-thunderbolt         |  9 ++++++++
 Documentation/admin-guide/thunderbolt.rst     | 23 +++++++++++++++++++
 drivers/thunderbolt/domain.c                  | 17 ++++++++++++++
 3 files changed, 49 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt b/Documentation/ABI/testing/sysfs-bus-thunderbolt
index 151584a1f950..b21fba14689b 100644
--- a/Documentation/ABI/testing/sysfs-bus-thunderbolt
+++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt
@@ -21,6 +21,15 @@ Description:	Holds a comma separated list of device unique_ids that
 		If a device is authorized automatically during boot its
 		boot attribute is set to 1.
 
+What: /sys/bus/thunderbolt/devices/.../domainX/iommu_dma_protection
+Date:		Mar 2019
+KernelVersion:	4.21
+Contact:	thunderbolt-software@lists.01.org
+Description:	This attribute tells whether the system uses IOMMU
+		for DMA protection. Value of 1 means IOMMU is used 0 means
+		it is not (DMA protection is solely based on Thunderbolt
+		security levels).
+
 What: /sys/bus/thunderbolt/devices/.../domainX/security
 Date:		Sep 2017
 KernelVersion:	4.13
diff --git a/Documentation/admin-guide/thunderbolt.rst b/Documentation/admin-guide/thunderbolt.rst
index 35fccba6a9a6..ccac2596a49f 100644
--- a/Documentation/admin-guide/thunderbolt.rst
+++ b/Documentation/admin-guide/thunderbolt.rst
@@ -133,6 +133,29 @@ If the user still wants to connect the device they can either approve
 the device without a key or write a new key and write 1 to the
 ``authorized`` file to get the new key stored on the device NVM.
 
+DMA protection utilizing IOMMU
+------------------------------
+Recent systems shipping with Windows 10 version 1803 or later may support a
+feature called `Kernel DMA Protection for Thunderbolt 3`_.  This means that
+Thunderbolt security is handled by an IOMMU so connected devices cannot
+access memory regions outside of what is allocated for them by drivers.
+When Linux is running on such system it automatically enables IOMMU if not
+enabled by the user already. These systems can be identified by reading
+``1`` from ``/sys/bus/thunderbolt/devices/domainX/iommu_dma_protection``
+attribute.
+
+The driver does not do anything special in this case but because DMA
+protection is handled by the IOMMU, security levels (if set) are
+redundant. For this reason some systems ship with security level set to
+``none``. Other systems have security level set to ``user`` in order to
+support downgrade to older Windows, so users who want to automatically
+authorize devices when IOMMU DMA protection is enabled can use the
+following ``udev`` rule::
+
+  ACTION=="add", SUBSYSTEM=="thunderbolt", ATTRS{iommu_dma_protection}=="1", ATTR{authorized}=="0", ATTR{authorized}="1"
+
+.. _Kernel DMA Protection for Thunderbolt 3: https://docs.microsoft.com/en-us/windows/security/information-protection/kernel-dma-protection-for-thunderbolt
+
 Upgrading NVM on Thunderbolt device or host
 -------------------------------------------
 Since most of the functionality is handled in firmware running on a
diff --git a/drivers/thunderbolt/domain.c b/drivers/thunderbolt/domain.c
index 93e562f18d40..7416bdbd8576 100644
--- a/drivers/thunderbolt/domain.c
+++ b/drivers/thunderbolt/domain.c
@@ -7,7 +7,9 @@
  */
 
 #include <linux/device.h>
+#include <linux/dmar.h>
 #include <linux/idr.h>
+#include <linux/iommu.h>
 #include <linux/module.h>
 #include <linux/pm_runtime.h>
 #include <linux/slab.h>
@@ -236,6 +238,20 @@ static ssize_t boot_acl_store(struct device *dev, struct device_attribute *attr,
 }
 static DEVICE_ATTR_RW(boot_acl);
 
+static ssize_t iommu_dma_protection_show(struct device *dev,
+					 struct device_attribute *attr,
+					 char *buf)
+{
+	/*
+	 * Kernel DMA protection is a feature where Thunderbolt security is
+	 * handled natively using IOMMU. It is enabled when IOMMU is
+	 * enabled and ACPI DMAR table has DMAR_PLATFORM_OPT_IN set.
+	 */
+	return sprintf(buf, "%d\n",
+		       iommu_present(&pci_bus_type) && dmar_platform_optin());
+}
+static DEVICE_ATTR_RO(iommu_dma_protection);
+
 static ssize_t security_show(struct device *dev, struct device_attribute *attr,
 			     char *buf)
 {
@@ -251,6 +267,7 @@ static DEVICE_ATTR_RO(security);
 
 static struct attribute *domain_attrs[] = {
 	&dev_attr_boot_acl.attr,
+	&dev_attr_iommu_dma_protection.attr,
 	&dev_attr_security.attr,
 	NULL,
 };
-- 
2.19.1


  parent reply	other threads:[~2018-11-12 16:06 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-12 16:06 [PATCH 0/4] PCI / iommu / thunderbolt: IOMMU based DMA protection Mika Westerberg
2018-11-12 16:06 ` [PATCH 1/4] PCI / ACPI: Identify external PCI devices Mika Westerberg
2018-11-12 18:02   ` Lukas Wunner
2018-11-13 10:56     ` Lorenzo Pieralisi
2018-11-13 11:27       ` Mika Westerberg
2018-11-13 11:45         ` Lorenzo Pieralisi
2018-11-15 10:22           ` Mika Westerberg
2018-11-15 11:13             ` Lorenzo Pieralisi
2018-11-15 11:37               ` Mika Westerberg
2018-11-15 12:07                 ` Lukas Wunner
2018-11-15 12:16                   ` Mika Westerberg
2018-11-15 17:46                     ` Lorenzo Pieralisi
2018-11-15 17:58                       ` Yehezkel Bernat
2018-11-15 19:10                         ` Mika Westerberg
2018-11-15 19:27                           ` Lukas Wunner
2018-11-15 19:32                             ` Mika Westerberg
2018-11-16  9:18                           ` Christoph Hellwig
2018-11-16  9:32                             ` Mika Westerberg
2018-11-22 10:48                               ` Mika Westerberg
2018-11-22 10:59                                 ` Christoph Hellwig
2018-11-15 19:00                       ` Mika Westerberg
2018-11-15 19:33                         ` Mario.Limonciello
2018-11-16 10:57                           ` Lorenzo Pieralisi
2018-11-20 21:43                             ` Rafael J. Wysocki
2018-11-21 12:40                               ` Lorenzo Pieralisi
2018-11-16  7:01                         ` Mika Westerberg
2018-11-12 16:06 ` [PATCH 2/4] iommu/vt-d: Force IOMMU on for platform opt in hint Mika Westerberg
2018-11-12 17:49   ` Raj, Ashok
2018-11-12 18:09   ` Alex Williamson
2018-11-12 19:51     ` Raj, Ashok
2018-11-12 16:06 ` [PATCH 3/4] iommu/vt-d: Do not enable ATS for external devices Mika Westerberg
2018-11-12 17:53   ` Raj, Ashok
2018-11-12 16:06 ` Mika Westerberg [this message]
2018-11-12 16:22   ` [PATCH 4/4] thunderbolt: Export IOMMU based DMA protection support to userspace Mario.Limonciello
2018-11-13 10:36     ` Mika Westerberg
2018-11-12 16:59   ` Yehezkel Bernat
2018-11-13 10:55     ` Mika Westerberg
2018-11-13 11:13       ` Yehezkel Bernat
2018-11-13 11:40         ` Mika Westerberg
2018-11-13 14:42           ` Yehezkel Bernat
     [not found]             ` <20181113152038.GD2500@lahna.fi.intel.com>
2018-11-13 15:38               ` Yehezkel Bernat
2018-11-13 16:12                 ` Mika Westerberg
2018-11-12 18:12 ` [PATCH 0/4] PCI / iommu / thunderbolt: IOMMU based DMA protection Lukas Wunner
2018-11-12 19:04   ` Yehezkel Bernat
2018-11-13 11:13   ` Mika Westerberg
2018-11-13  8:54 ` Joerg Roedel
2018-11-13 11:32   ` Mika Westerberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181112160628.86620-5-mika.westerberg@linux.intel.com \
    --to=mika.westerberg@linux.intel.com \
    --cc=Mario.Limonciello@dell.com \
    --cc=YehezkelShB@gmail.com \
    --cc=andreas.noever@gmail.com \
    --cc=anthony.wong@canonical.com \
    --cc=ashok.raj@intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=bhelgaas@google.com \
    --cc=ckellner@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jacob.jun.pan@intel.com \
    --cc=joro@8bytes.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=michael.jamet@intel.com \
    --cc=rjw@rjwysocki.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).