linux-kernel - Re: [PATCH 0/4] Enable PASID for DMA API users

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: <20211208131038.GQ6385@nvidia.com>
Date:   Wed, 8 Dec 2021 09:10:38 -0400
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Jacob Pan <jacob.jun.pan@...ux.intel.com>
Cc:     iommu@...ts.linux-foundation.org,
        LKML <linux-kernel@...r.kernel.org>,
        Joerg Roedel <joro@...tes.org>,
        Christoph Hellwig <hch@...radead.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jean-Philippe Brucker <jean-philippe@...aro.com>,
        Jacob Pan <jacob.jun.pan@...el.com>,
        Lu Baolu <baolu.lu@...ux.intel.com>,
        Raj Ashok <ashok.raj@...el.com>,
        "Kumar, Sanjay K" <sanjay.k.kumar@...el.com>,
        Dave Jiang <dave.jiang@...el.com>,
        Tony Luck <tony.luck@...el.com>, Yi Liu <yi.l.liu@...el.com>,
        "Tian, Kevin" <kevin.tian@...el.com>,
        Barry Song <21cnbao@...il.com>,
        "Zanussi, Tom" <tom.zanussi@...el.com>,
        Dan Williams <dan.j.williams@...el.com>
Subject: Re: [PATCH 0/4] Enable PASID for DMA API users

On Tue, Dec 07, 2021 at 05:47:10AM -0800, Jacob Pan wrote:
> Modern accelerators such as Intel's Data Streaming Accelerator (DSA) can
> perform DMA requests with PASID, which is a finer granularity than the
> device's requester ID(RID). In fact, work submissions on DSA shared work
> queues require PASID.

Lets use plain langauge please:

DSA HW cannot do DMA from its RID, so always requires a PASID, even
for kernel controlled DMA.

To allow it to use the DMA API we must associate a PASID with the
iommu_domain that the DMA API is already using for the device's RID.

This way DMA tagged with the PASID will be treated exactly the same as
DMA originating from the RID.

> DMA mapping API is the de facto standard for in-kernel DMA. However, it
> operates on a per device/RID basis which is not PASID-aware.
> 
> This patch introduces the following driver facing API that enables DMA API
> PASID usage: ioasid_t iommu_enable_pasid_dma(struct device *dev);

This is the wrong API, IMHO

It should be more like

int iommu_get_dma_api_pasid(struct device *dev, ioasid_t *pasid);
void iommu_destroy_dma_api_pasid(struct device *dev);

> A PASID field is added to struct device for the purposes of storing kernel
> DMA PASID and flushing device IOTLBs. A separate use case in interrupt

And this really should not be touching the struct device at all.

At worst the PASID should be stored in the iommu_group.

> message store (IMS) also hinted adding a PASID field to struct device.
> https://lore.kernel.org/all/87pmx73tfw.ffs@nanos.tec.linutronix.de/
> IMS virtualization and DMA API does not overlap.

This is under debate, I'm skeptical it will happen considering the new
direction for this work.

> Once enabled, device drivers can continue to use DMA APIs as-is. There is
> no difference in terms of mapping in dma_handle between without PASID and
> with PASID.  The DMA mapping performed by IOMMU will be identical for both
> requests with and without PASID (legacy), let it be IOVA or PA in case of
> pass-through.

In other words all this does is connect the PASID to the normal
DMA-API owned iommu_domain.

Jason