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
next prev 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: linkBe 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.