diff mbox series

[2/6] drivers: base: Add bits to struct device to control iommu strictness

Message ID 20210621165230.2.Icfe7cbb2cc86a38dde0ee5ba240e0580a0ec9596@changeid
State New
Headers show
Series iommu: Enable devices to request non-strict DMA, starting with QCom SD/MMC | expand

Commit Message

Doug Anderson June 21, 2021, 11:52 p.m. UTC
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(+)

Comments

Greg Kroah-Hartman June 24, 2021, 1:36 p.m. UTC | #1
On Mon, Jun 21, 2021 at 04:52:44PM -0700, Douglas Anderson wrote:
> 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.


Why would you ever NOT want to do this?

> + * @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.


This feels in contrast to the previous field you just added, how do they
both interact?  Would an enum work better?

thanks,

greg k-h
diff mbox series

Patch

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;
 };
 
 /**