linux-kernel - RE: [PATCH 00/12] Consolidate domain cache invalidation

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <BN9PR11MB5276B476EC7C098E153ABF168C002@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Mon, 8 Apr 2024 03:03:19 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Baolu Lu <baolu.lu@...ux.intel.com>, Joerg Roedel <joro@...tes.org>, "Will
 Deacon" <will@...nel.org>, Robin Murphy <robin.murphy@....com>, "Jason
 Gunthorpe" <jgg@...pe.ca>
CC: "Zhang, Tina" <tina.zhang@...el.com>, "Liu, Yi L" <yi.l.liu@...el.com>,
	"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 00/12] Consolidate domain cache invalidation

> From: Baolu Lu <baolu.lu@...ux.intel.com>
> Sent: Sunday, April 7, 2024 3:28 PM
> 
> On 3/28/24 3:59 PM, Tian, Kevin wrote:
> >> From: Lu Baolu<baolu.lu@...ux.intel.com>
> >> Sent: Monday, March 25, 2024 10:17 AM
> >>
> >> The IOMMU hardware cache needs to be invalidated whenever the
> >> mappings
> >> in the domain are changed. Currently, domain cache invalidation is
> >> scattered across different places, causing several issues:
> >>
> >> - IOMMU IOTLB Invalidation: This is done by iterating through the domain
> >>    IDs of each domain using the following code:
> >>
> >>          xa_for_each(&dmar_domain->iommu_array, i, info)
> >>                  iommu_flush_iotlb_psi(info->iommu, dmar_domain,
> >>                                        start_pfn, nrpages,
> >>                                        list_empty(&gather->freelist), 0);
> >>
> >>    This code could theoretically cause a use-after-free problem because
> >>    there's no lock to protect the "info" pointer within the loop.
> >>
> >> - Inconsistent Invalidation Methods: Different domain types implement
> >>    their own cache invalidation methods, making the code difficult to
> >>    maintain. For example, the DMA domain, SVA domain, and nested
> domain
> >>    have similar cache invalidation code scattered across different files.
> >>
> >> - SVA Domain Inconsistency: The SVA domain implementation uses a
> >>    completely different data structure to track attached devices compared
> >>    to other domains. This creates unnecessary differences and, even
> >>    worse, leads to duplicate IOTLB invalidation when an SVA domain is
> >>    attached to devices belonging to different IOMMU domains.
> > can you elaborate how duplicated invalidations are caused?
> 
> Yes, sure.
> 
> Current Intel SVA implementation keeps the bond between mm and a PASID
> of a device in a list of intel_svm_dev. In the mm notifier callback, it
> iterates all intel_svam_dev in the list and invalidates the IOTLB and
> device TLB sequentially.
> 
> If multiple devices belong to a single IOMMU, the IOTLB will be flushed
> multiple times. However, since these devices share the same domain ID
> and PASID, a single IOTLB cache invalidation is sufficient. The
> additional flushes are redundant and negatively impact performance.
> 

yes it's redundant. But what does "devices belonging to different
IOMMU domains" in the original context try to convey? From above
explanation it sounds irrelevant...