lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2024111818-molecule-pedicure-db1b@gregkh>
Date: Mon, 18 Nov 2024 20:43:00 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Joshua Peraza <jperaza@...gle.com>
Cc: baolu.lu@...ux.intel.com, bhelgaas@...gle.com, dtor@...gle.com,
	dwmw2@...radead.org, helgaas@...nel.org,
	iommu@...ts.linux-foundation.org, jean-philippe@...aro.org,
	joro@...tes.org, jsbarnes@...gle.com, lenb@...nel.org,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-pci@...r.kernel.org, mika.westerberg@...ux.intel.com,
	oohall@...il.com, pavel@...x.de, rafael.j.wysocki@...el.com,
	rafael@...nel.org, rajatja@...gle.com, rajatxjain@...il.com,
	will@...nel.org
Subject: Re: [v8 PATCH 0/2] PCI/ACPI: Support Microsoft's "DmaProperty"

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ