All of lore.kernel.org
 help / color / mirror / Atom feed
From: Douglas Anderson <dianders@chromium.org>
To: gregkh@linuxfoundation.org, rafael@kernel.org,
	rafael.j.wysocki@intel.com, will@kernel.org,
	robin.murphy@arm.com, joro@8bytes.org,
	bjorn.andersson@linaro.org, ulf.hansson@linaro.org,
	adrian.hunter@intel.com, bhelgaas@google.com
Cc: robdclark@chromium.org, linux-arm-msm@vger.kernel.org,
	linux-pci@vger.kernel.org, quic_c_gdjako@quicinc.com,
	iommu@lists.linux-foundation.org, sonnyrao@chromium.org,
	saiprakash.ranjan@codeaurora.org, linux-mmc@vger.kernel.org,
	vbadigan@codeaurora.org, rajatja@google.com,
	saravanak@google.com, joel@joelfernandes.org,
	Douglas Anderson <dianders@chromium.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	linux-kernel@vger.kernel.org
Subject: [PATCH 2/6] drivers: base: Add bits to struct device to control iommu strictness
Date: Mon, 21 Jun 2021 16:52:44 -0700	[thread overview]
Message-ID: <20210621165230.2.Icfe7cbb2cc86a38dde0ee5ba240e0580a0ec9596@changeid> (raw)
In-Reply-To: <20210621235248.2521620-1-dianders@chromium.org>

How to control the "strictness" of an IOMMU is a bit of a mess right
now. As far as I can tell, right now:
* You can set the default to "non-strict" and some devices (right now,
  only PCI devices) can request to run in "strict" mode.
* You can set the default to "strict" and no devices in the system are
  allowed to run as "non-strict".

I believe this needs to be improved a bit. Specifically:
* We should be able to default to "strict" mode but let devices that
  claim to be fairly low risk request that they be run in "non-strict"
  mode.
* We should allow devices outside of PCIe to request "strict" mode if
  the system default is "non-strict".

I believe the correct way to do this is two bits in "struct
device". One allows a device to force things to "strict" mode and the
other allows a device to _request_ "non-strict" mode. The asymmetry
here is on purpose. Generally if anything in the system makes a
request for strictness of something then we want it strict. Thus
drivers can only request (but not force) non-strictness.

It's expected that the strictness fields can be filled in by the bus
code like in the patch ("PCI: Indicate that we want to force strict
DMA for untrusted devices") or by using the new pre_probe concept
introduced in the patch ("drivers: base: Add the concept of
"pre_probe" to drivers").

Signed-off-by: Douglas Anderson <dianders@chromium.org>
---

 include/linux/device.h | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/device.h b/include/linux/device.h
index f1a00040fa53..c1b985e10c47 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -449,6 +449,15 @@ struct dev_links_info {
  *		and optionall (if the coherent mask is large enough) also
  *		for dma allocations.  This flag is managed by the dma ops
  *		instance from ->dma_supported.
+ * @force_strict_iommu: If set to %true then we should force this device to
+ *			iommu.strict regardless of the other defaults in the
+ *			system. Only has an effect if an IOMMU is in place.
+ * @request_non_strict_iommu: If set to %true and there are no other known
+ *			      reasons to make the iommu.strict for this device,
+ *			      then default to non-strict mode. This implies
+ *			      some belief that the DMA master for this device
+ *			      won't abuse the DMA path to compromise the kernel.
+ *			      Only has an effect if an IOMMU is in place.
  *
  * At the lowest level, every device in a Linux system is represented by an
  * instance of struct device. The device structure contains the information
@@ -557,6 +566,8 @@ struct device {
 #ifdef CONFIG_DMA_OPS_BYPASS
 	bool			dma_ops_bypass : 1;
 #endif
+	bool			force_strict_iommu:1;
+	bool			request_non_strict_iommu:1;
 };
 
 /**
-- 
2.32.0.288.g62a8d224e6-goog


WARNING: multiple messages have this Message-ID (diff)
From: Douglas Anderson <dianders@chromium.org>
To: gregkh@linuxfoundation.org, rafael@kernel.org,
	rafael.j.wysocki@intel.com, will@kernel.org,
	robin.murphy@arm.com, joro@8bytes.org,
	bjorn.andersson@linaro.org, ulf.hansson@linaro.org,
	adrian.hunter@intel.com, bhelgaas@google.com
Cc: robdclark@chromium.org,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	linux-kernel@vger.kernel.org, saravanak@google.com,
	linux-arm-msm@vger.kernel.org,
	Randy Dunlap <rdunlap@infradead.org>,
	linux-mmc@vger.kernel.org, quic_c_gdjako@quicinc.com,
	Douglas Anderson <dianders@chromium.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	iommu@lists.linux-foundation.org, linux-pci@vger.kernel.org,
	joel@joelfernandes.org, Dan Williams <dan.j.williams@intel.com>,
	rajatja@google.com, sonnyrao@chromium.org,
	vbadigan@codeaurora.org
Subject: [PATCH 2/6] drivers: base: Add bits to struct device to control iommu strictness
Date: Mon, 21 Jun 2021 16:52:44 -0700	[thread overview]
Message-ID: <20210621165230.2.Icfe7cbb2cc86a38dde0ee5ba240e0580a0ec9596@changeid> (raw)
In-Reply-To: <20210621235248.2521620-1-dianders@chromium.org>

How to control the "strictness" of an IOMMU is a bit of a mess right
now. As far as I can tell, right now:
* You can set the default to "non-strict" and some devices (right now,
  only PCI devices) can request to run in "strict" mode.
* You can set the default to "strict" and no devices in the system are
  allowed to run as "non-strict".

I believe this needs to be improved a bit. Specifically:
* We should be able to default to "strict" mode but let devices that
  claim to be fairly low risk request that they be run in "non-strict"
  mode.
* We should allow devices outside of PCIe to request "strict" mode if
  the system default is "non-strict".

I believe the correct way to do this is two bits in "struct
device". One allows a device to force things to "strict" mode and the
other allows a device to _request_ "non-strict" mode. The asymmetry
here is on purpose. Generally if anything in the system makes a
request for strictness of something then we want it strict. Thus
drivers can only request (but not force) non-strictness.

It's expected that the strictness fields can be filled in by the bus
code like in the patch ("PCI: Indicate that we want to force strict
DMA for untrusted devices") or by using the new pre_probe concept
introduced in the patch ("drivers: base: Add the concept of
"pre_probe" to drivers").

Signed-off-by: Douglas Anderson <dianders@chromium.org>
---

 include/linux/device.h | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/device.h b/include/linux/device.h
index f1a00040fa53..c1b985e10c47 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -449,6 +449,15 @@ struct dev_links_info {
  *		and optionall (if the coherent mask is large enough) also
  *		for dma allocations.  This flag is managed by the dma ops
  *		instance from ->dma_supported.
+ * @force_strict_iommu: If set to %true then we should force this device to
+ *			iommu.strict regardless of the other defaults in the
+ *			system. Only has an effect if an IOMMU is in place.
+ * @request_non_strict_iommu: If set to %true and there are no other known
+ *			      reasons to make the iommu.strict for this device,
+ *			      then default to non-strict mode. This implies
+ *			      some belief that the DMA master for this device
+ *			      won't abuse the DMA path to compromise the kernel.
+ *			      Only has an effect if an IOMMU is in place.
  *
  * At the lowest level, every device in a Linux system is represented by an
  * instance of struct device. The device structure contains the information
@@ -557,6 +566,8 @@ struct device {
 #ifdef CONFIG_DMA_OPS_BYPASS
 	bool			dma_ops_bypass : 1;
 #endif
+	bool			force_strict_iommu:1;
+	bool			request_non_strict_iommu:1;
 };
 
 /**
-- 
2.32.0.288.g62a8d224e6-goog

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  parent reply	other threads:[~2021-06-21 23:53 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-21 23:52 [PATCH 0/6] iommu: Enable devices to request non-strict DMA, starting with QCom SD/MMC Douglas Anderson
2021-06-21 23:52 ` Douglas Anderson
2021-06-21 23:52 ` [PATCH 1/6] drivers: base: Add the concept of "pre_probe" to drivers Douglas Anderson
2021-06-21 23:52   ` Douglas Anderson
2021-06-24 13:35   ` Greg KH
2021-06-24 13:35     ` Greg KH
2021-06-21 23:52 ` Douglas Anderson [this message]
2021-06-21 23:52   ` [PATCH 2/6] drivers: base: Add bits to struct device to control iommu strictness Douglas Anderson
2021-06-24 13:36   ` Greg KH
2021-06-24 13:36     ` Greg KH
2021-06-24 13:42     ` Doug Anderson
2021-06-24 13:42       ` Doug Anderson
2021-06-21 23:52 ` [PATCH 3/6] PCI: Indicate that we want to force strict DMA for untrusted devices Douglas Anderson
2021-06-21 23:52   ` Douglas Anderson
2021-06-24 13:38   ` Greg KH
2021-06-24 13:38     ` Greg KH
2021-06-24 13:46     ` Doug Anderson
2021-06-24 13:46       ` Doug Anderson
2021-06-21 23:52 ` [PATCH 4/6] iommu: Combine device strictness requests with the global default Douglas Anderson
2021-06-21 23:52   ` Douglas Anderson
2021-06-22  2:03   ` Lu Baolu
2021-06-22  2:03     ` Lu Baolu
2021-06-22 16:53     ` Doug Anderson
2021-06-22 16:53       ` Doug Anderson
2021-06-22 17:01       ` Doug Anderson
2021-06-22 17:01         ` Doug Anderson
2021-06-22  2:55   ` Saravana Kannan
2021-06-22  2:55     ` Saravana Kannan via iommu
2021-06-22 16:40     ` Doug Anderson
2021-06-22 16:40       ` Doug Anderson
2021-06-22 19:50       ` Saravana Kannan
2021-06-22 19:50         ` Saravana Kannan via iommu
2021-06-22 11:49   ` Robin Murphy
2021-06-22 11:49     ` Robin Murphy
2021-06-22 18:45   ` Rajat Jain
2021-06-22 18:45     ` Rajat Jain via iommu
2021-06-22 19:35     ` Doug Anderson
2021-06-22 19:35       ` Doug Anderson
2021-06-21 23:52 ` [PATCH 5/6] iommu: Stop reaching into PCIe devices to decide strict vs. non-strict Douglas Anderson
2021-06-21 23:52   ` Douglas Anderson
2021-06-21 23:52 ` [PATCH 6/6] mmc: sdhci-msm: Request non-strict IOMMU mode Douglas Anderson
2021-06-21 23:52   ` Douglas Anderson
2021-06-24 13:43   ` Greg KH
2021-06-24 13:43     ` Greg KH
2021-06-24 14:00     ` Doug Anderson
2021-06-24 14:00       ` Doug Anderson
2021-06-22 11:35 ` [PATCH 0/6] iommu: Enable devices to request non-strict DMA, starting with QCom SD/MMC Robin Murphy
2021-06-22 11:35   ` Robin Murphy
2021-06-22 16:06   ` Doug Anderson
2021-06-22 16:06     ` Doug Anderson
2021-06-22 20:02     ` Rob Herring
2021-06-22 20:02       ` Rob Herring
2021-06-22 20:05       ` Saravana Kannan
2021-06-22 20:05         ` Saravana Kannan via iommu
2021-06-22 20:10         ` Doug Anderson
2021-06-22 20:10           ` Doug Anderson
2021-06-23 13:54           ` Rob Herring
2021-06-23 13:54             ` Rob Herring
2021-06-22 22:10     ` Robin Murphy
2021-06-22 22:10       ` Robin Murphy
2021-06-23 17:29       ` Doug Anderson
2021-06-23 17:29         ` Doug Anderson
2021-06-24 17:23         ` Doug Anderson
2021-06-24 17:23           ` Doug Anderson
2021-06-22 17:39 ` John Garry
2021-06-22 17:39   ` John Garry
2021-06-22 19:50   ` Doug Anderson
2021-06-22 19:50     ` Doug Anderson

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=20210621165230.2.Icfe7cbb2cc86a38dde0ee5ba240e0580a0ec9596@changeid \
    --to=dianders@chromium.org \
    --cc=adrian.hunter@intel.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=bhelgaas@google.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=dan.j.williams@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joel@joelfernandes.org \
    --cc=joro@8bytes.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=quic_c_gdjako@quicinc.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rafael@kernel.org \
    --cc=rajatja@google.com \
    --cc=rdunlap@infradead.org \
    --cc=robdclark@chromium.org \
    --cc=robin.murphy@arm.com \
    --cc=saiprakash.ranjan@codeaurora.org \
    --cc=saravanak@google.com \
    --cc=sonnyrao@chromium.org \
    --cc=ulf.hansson@linaro.org \
    --cc=vbadigan@codeaurora.org \
    --cc=will@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.