linux-kernel - Re: [PATCH v10 04/12] iommu: Add attach/detach_dev

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: <YuPQ6om0gELPqoiu@nvidia.com>
Date:   Fri, 29 Jul 2022 09:22:02 -0300
From:   Jason Gunthorpe <jgg@...dia.com>
To:     "Tian, Kevin" <kevin.tian@...el.com>
Cc:     Baolu Lu <baolu.lu@...ux.intel.com>,
        Joerg Roedel <joro@...tes.org>,
        Christoph Hellwig <hch@...radead.org>,
        "Raj, Ashok" <ashok.raj@...el.com>, Will Deacon <will@...nel.org>,
        Robin Murphy <robin.murphy@....com>,
        Jean-Philippe Brucker <jean-philippe@...aro.com>,
        "Jiang, Dave" <dave.jiang@...el.com>,
        Vinod Koul <vkoul@...nel.org>,
        Eric Auger <eric.auger@...hat.com>,
        "Liu, Yi L" <yi.l.liu@...el.com>,
        "Pan, Jacob jun" <jacob.jun.pan@...el.com>,
        Zhangfei Gao <zhangfei.gao@...aro.org>,
        "Zhu, Tony" <tony.zhu@...el.com>,
        "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Jean-Philippe Brucker <jean-philippe@...aro.org>
Subject: Re: [PATCH v10 04/12] iommu: Add attach/detach_dev_pasid iommu
 interface

On Fri, Jul 29, 2022 at 02:51:02AM +0000, Tian, Kevin wrote:
> > From: Jason Gunthorpe <jgg@...dia.com>
> > Sent: Thursday, July 28, 2022 8:00 PM
> > 
> > On Thu, Jul 28, 2022 at 03:06:47AM +0000, Tian, Kevin wrote:
> > 
> > > > Then we don't need this weirdo check in the core iommu code at all.
> > >
> > > and then we could also move group->pasid_array to device->pasid_array
> > > with this approach. Though the end result doesn't change i.e. still only
> > > the singleton group can enable pasid the iommu core can just stick to
> > > the device manner now.
> > 
> > I don't see why, the group is still logically the unit of attachment
> > in the iommu area, and if we have a multi-device group it just means
> > we iterate over all the devices in the group when doing pasid set, no
> > different than a RID.
> 
> Probably I overthought about this.
> 
> To enable PASID in a multi-device group one prerequisite is to reserve
> P2P ranges of the group in the related address space (let's assume 
> there is a way to do that reservation).

No, that isn't the requirement - the only requirement is that every TLP
marked with a PASID is routed to the host bridge and only the host
bridge.

ACS achieves this universally, that is what it means in PCI.

We should not even think about supporting PASID in environments where
there is address routing present because it will never work properly
(eg SVA is a complete no-go)

> But for a group created due to RID mess e.g. PCI bridge the PASID table
> has to be shared by the entire group. 

A legacy PCI bridge will be without ACS so it already fails the ACS
test. No issue.

The RID issue is that we can't reliably tell the source apart in a
group - so all the RIDs in a group have to be considered as the same
RID, and mapped to the same PASID table.

But that is the only restriction of a group we have left, because the
'iommu doesn't isolate all traffic' restriction is defined not to
exist if PASID is supported.

> So yes, from this angle leaving one table per group is a simpler
> thing to do, especially when it's unclear whether there is real
> demand to enable PASID for multi-device group. 😊

Except it is confusing, complicated and unnecessary. Treating PASID of
multi-device groups the same as everything else is logically simple.

Jason