mbox series

[v8,0/2] PCI/ACPI: Support Microsoft's "DmaProperty"

Message ID 20241118193024.2695876-1-jperaza@google.com (mailing list archive)
Headers show
Series PCI/ACPI: Support Microsoft's "DmaProperty" | expand

Message

Joshua Peraza Nov. 18, 2024, 7:30 p.m. UTC
This patchset rebases two previously posted patches supporting
recognition of Microsoft's DmaProperty.

v8: Joshua renames untrusted_dma to requires_dma_protection and updates
some comments, reducing use of the word "trust" to refer to PCI devices
and matching the word choice in Microsoft's documentation.

v7: Rajat updates a comment with Robin's suggestion. Joshua re-sends and
Greg requests clarity and documentation on why untrusted_dma is the
right name.

v6: Rajat renames pci_dev_has_dma_property and links to Microsoft's
documentation in the commit message. Robin suggests clarifying a
comment.

v5: Rajat changes the name to untrusted_dma. Bjorn suggesting changing
another function's name pci_acpi_check_for_dma_protection to
pci_dev_has_dma_property and seeks clarified documentation.

v4: Rajat changes the name to poses_dma_risk. Christoph suggests this
name doesn't capture the intent as well as untrusted_dma and Rafael
agrees.

v1,v2,v3: Greg suggests that (un)trusted is the wrong word for referring
to PCI devices, recommending a name something like "platform wants to
protect dma access for this device."


Rajat Jain (2):
  PCI/ACPI: Support Microsoft's "DmaProperty"
  PCI: Rename pci_dev->untrusted to pci_dev->requires_dma_protection

 drivers/acpi/property.c     |  3 +++
 drivers/iommu/amd/iommu.c   |  3 +--
 drivers/iommu/dma-iommu.c   | 16 ++++++++--------
 drivers/iommu/intel/iommu.c | 10 +++++-----
 drivers/iommu/iommu.c       |  5 ++---
 drivers/pci/ats.c           |  2 +-
 drivers/pci/pci-acpi.c      | 22 ++++++++++++++++++++++
 drivers/pci/pci.c           |  2 +-
 drivers/pci/probe.c         |  8 ++++----
 drivers/pci/quirks.c        |  4 ++--
 include/linux/pci.h         |  7 ++++---
 11 files changed, 53 insertions(+), 29 deletions(-)


base-commit: 2d5404caa8c7bb5c4e0435f94b28834ae5456623

Comments

Greg KH Nov. 18, 2024, 7:43 p.m. UTC | #1
On Mon, Nov 18, 2024 at 07:30:22PM +0000, Joshua Peraza wrote:
> This patchset rebases two previously posted patches supporting
> recognition of Microsoft's DmaProperty.
> 
> v8: Joshua renames untrusted_dma to requires_dma_protection and updates
> some comments, reducing use of the word "trust" to refer to PCI devices
> and matching the word choice in Microsoft's documentation.

So this is the "clarity"?  I'm not sold, sorry.  Again, did you look at
the previous discussions we had about this name?  We don't have to use
Microsoft's term here as it is used differently by Linux today, right?
If you really want to support the DmaProperty, why not just support that
with a new bit as that's something different here, right?

Again, look at what this is supposed to be conveying.  They ability to
DMA to anywhere isn't really the root issue here, or is it?  What is the
threat model you are trying to mitigate?

> v7: Rajat updates a comment with Robin's suggestion. Joshua re-sends and
> Greg requests clarity and documentation on why untrusted_dma is the
> right name.
> 
> v6: Rajat renames pci_dev_has_dma_property and links to Microsoft's
> documentation in the commit message. Robin suggests clarifying a
> comment.
> 
> v5: Rajat changes the name to untrusted_dma. Bjorn suggesting changing
> another function's name pci_acpi_check_for_dma_protection to
> pci_dev_has_dma_property and seeks clarified documentation.
> 
> v4: Rajat changes the name to poses_dma_risk. Christoph suggests this
> name doesn't capture the intent as well as untrusted_dma and Rafael
> agrees.
> 
> v1,v2,v3: Greg suggests that (un)trusted is the wrong word for referring
> to PCI devices, recommending a name something like "platform wants to
> protect dma access for this device."

Or is it?  I said this when?  Just how old is this patch series?

confused,

greg k-h