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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BN9PR11MB52768891BC89107AD291E45C8CE6A@BN9PR11MB5276.namprd11.prod.outlook.com>
Date:   Wed, 30 Aug 2023 07:43:57 +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>,
        Jean-Philippe Brucker <jean-philippe@...aro.org>,
        Nicolin Chen <nicolinc@...dia.com>
CC:     "Liu, Yi L" <yi.l.liu@...el.com>,
        Jacob Pan <jacob.jun.pan@...ux.intel.com>,
        "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v4 09/10] iommu: Make iommu_queue_iopf() more generic

> From: Baolu Lu <baolu.lu@...ux.intel.com>
> Sent: Saturday, August 26, 2023 4:01 PM
> 
> On 8/25/23 4:17 PM, Tian, Kevin wrote:
> >> +
> >>   /**
> >>    * iopf_queue_flush_dev - Ensure that all queued faults have been
> >> processed
> >>    * @dev: the endpoint whose faults need to be flushed.
> > Presumably we also need a flush callback per domain given now
> > the use of workqueue is optional then flush_workqueue() might
> > not be sufficient.
> >
> 
> The iopf_queue_flush_dev() function flushes all pending faults from the
> IOMMU queue for a specific device. It has no means to flush fault queues
> out of iommu core.
> 
> The iopf_queue_flush_dev() function is typically called when a domain is
> detaching from a PASID. Hence it's necessary to flush the pending faults
> from top to bottom. For example, iommufd should flush pending faults in
> its fault queues after detaching the domain from the pasid.
> 

Is there an ordering problem? The last step of intel_svm_drain_prq()
in the detaching path issues a set of descriptors to drain page requests
and responses in hardware. It cannot complete if not all software queues
are drained and it's counter-intuitive to drain a software queue after 
the hardware draining has already been completed.

btw just flushing requests is probably insufficient in iommufd case since
the responses are received asynchronously. It requires an interface to
drain both requests and responses (presumably with timeouts in case
of a malicious guest which never responds) in the detach path.

it's not a problem for sva as responses are synchrounsly delivered after
handling mm fault. So fine to not touch it in this series but certainly
this area needs more work when moving to support iommufd. 😊

btw why is iopf_queue_flush_dev() called only in intel-iommu driver?
Isn't it a common requirement for all sva-capable drivers?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ