linux-kernel - RE: [PATCH 6/7] iommu: Use right way to retrieve iommu

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: <BN9PR11MB5276004DA74B04B95D6A3CBB8C5F9@BN9PR11MB5276.namprd11.prod.outlook.com>
Date:   Tue, 25 Jan 2022 02:08:03 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Robin Murphy <robin.murphy@....com>,
        Jason Gunthorpe <jgg@...dia.com>,
        "Lu Baolu" <baolu.lu@...ux.intel.com>
CC:     "Raj, Ashok" <ashok.raj@...el.com>,
        David Airlie <airlied@...ux.ie>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Christoph Hellwig <hch@...radead.org>,
        Alex Williamson <alex.williamson@...hat.com>,
        "Thierry Reding" <thierry.reding@...il.com>,
        Ben Skeggs <bskeggs@...hat.com>,
        "Daniel Vetter" <daniel@...ll.ch>, Will Deacon <will@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Pan, Jacob jun" <jacob.jun.pan@...el.com>
Subject: RE: [PATCH 6/7] iommu: Use right way to retrieve iommu_ops

> From: Robin Murphy <robin.murphy@....com>
> Sent: Tuesday, January 25, 2022 9:52 AM
> 
> On 2022-01-25 01:11, Tian, Kevin wrote:
> >> From: Jason Gunthorpe via iommu
> >> Sent: Tuesday, January 25, 2022 1:37 AM
> >>> @@ -1295,7 +1298,7 @@ int iommu_page_response(struct device *dev,
> >>>   			msg->pasid = 0;
> >>>   		}
> >>>
> >>> -		ret = domain->ops->page_response(dev, evt, msg);
> >>> +		ret = ops->page_response(dev, evt, msg);
> >>>   		list_del(&evt->list);
> >>>   		kfree(evt);
> >>>   		break;
> >>
> >> Feels weird that page_response is not connected to a domain, the fault
> >> originated from a domain after all. I would say this op should be
> >> moved to the domain and the caller should provide the a pointer to the
> >> domain that originated the fault.
> >>
> >
> > In concept yes.
> 
> Not even that, really. It's true that the "fault" itself is logically
> associated with the domain, but we never see that - the ATS request and
> response which encapsulate it all happen automatically on the PCI side.
> It's the endpoint that then decides to handle ATS translation failure
> via PRI, so all we actually get is a page request message from a
> RID/PASID, which most definitely represents the "device" (and in fact
> having to work backwards from there to figure out which domain/context
> it is currently attached to can be a bit of a pain). Similarly the
> response is a message directly back to the device itself - an operation
> on a domain may (or may not) have happened off the back of receiving the
> initial request, but even if the content of the response is to reflect
> that, the operation of responding is clearly focused on the device.
> 
> I fully agree that it's a weird-looking model, but that's how PCI SIG
> made it - and no IOMMU architecture seems to have tried to wrap it up in
> anything nicer either - so I don't see that we'd gain much from trying
> to pretend otherwise :)
> 

I think the point here is that although page requests are received
per device from the wire the low level iommu driver should convert
those requests into domain-wide requests (with RID/PASID recorded
as private data in the request) which then can be handled by domain 
ops in iommu core. Once a domain-wide request is completed by 
the iommu core, the low level iommu driver then retrieves RID/PASID 
information from private data of the completed request and triggers 
page response per RID/PASID in bus specific way.

Does it sound reasonable?

Thanks
Kevin