linux-kernel - Re: [PATCH v5 01/14] iommu: Add dma ownership management interfaces

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]

Date:   Fri, 7 Jan 2022 09:50:06 +0800
From:   Lu Baolu <baolu.lu@...ux.intel.com>
To:     Jason Gunthorpe <jgg@...dia.com>
Cc:     baolu.lu@...ux.intel.com, Bjorn Helgaas <helgaas@...nel.org>,
        Christoph Hellwig <hch@...radead.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Joerg Roedel <joro@...tes.org>,
        Alex Williamson <alex.williamson@...hat.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Kevin Tian <kevin.tian@...el.com>,
        Ashok Raj <ashok.raj@...el.com>, Will Deacon <will@...nel.org>,
        Robin Murphy <robin.murphy@....com>,
        Dan Williams <dan.j.williams@...el.com>, rafael@...nel.org,
        Diana Craciun <diana.craciun@....nxp.com>,
        Cornelia Huck <cohuck@...hat.com>,
        Eric Auger <eric.auger@...hat.com>,
        Liu Yi L <yi.l.liu@...el.com>,
        Jacob jun Pan <jacob.jun.pan@...el.com>,
        Chaitanya Kulkarni <kch@...dia.com>,
        Stuart Yoder <stuyoder@...il.com>,
        Laurentiu Tudor <laurentiu.tudor@....com>,
        Thierry Reding <thierry.reding@...il.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Li Yang <leoyang.li@....com>,
        Dmitry Osipenko <digetx@...il.com>,
        iommu@...ts.linux-foundation.org, linux-pci@...r.kernel.org,
        kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 01/14] iommu: Add dma ownership management interfaces

On 1/6/22 11:46 PM, Jason Gunthorpe wrote:
> On Thu, Jan 06, 2022 at 11:54:06AM +0800, Lu Baolu wrote:
>> On 1/5/22 3:23 AM, Jason Gunthorpe wrote:
>>>>>> The device driver oriented interfaces are,
>>>>>>
>>>>>> 	int iommu_device_use_dma_api(struct device *dev);
>>>>>> 	void iommu_device_unuse_dma_api(struct device *dev);
>>>> Nit, do we care whether it uses the actual DMA API?  Or is it just
>>>> that iommu_device_use_dma_api() tells us the driver may program the
>>>> device to do DMA?
>>> As the main purpose, yes this is all about the DMA API because it
>>> asserts the group domain is the DMA API's domain.
>>>
>>> There is a secondary purpose that has to do with the user/kernel
>>> attack you mentioned above. Maintaining the DMA API domain also
>>> prevents VFIO from allowing userspace to operate any device in the
>>> group which blocks P2P attacks to MMIO of other devices.
>>>
>>> This is why, even if the driver doesn't use DMA, it should still do a
>>> iommu_device_use_dma_api(), except in the special cases where we don't
>>> care about P2P attacks (eg pci-stub, bridges, etc).
>>>
>>
>> By the way, use_dma_api seems hard to read. How about
>>
>> 	iommu_device_use_default_dma()?
> 
> You could just say "use default domain"
> 
> IMHO the way the iommu subsystem has its own wonky language is a
> little troublesome. In the rest of the kernel we call this the DMA
> API, while the iommu subsystem calls the domain that the DMA API uses
> the 'default domain' not the 'DMA API' domain.
> 
> Still, it is probably better to align to the iommu language - just be
> sure to put in the function comment that this API 'allows the driver
> to use the DMA API eg dma_map_sg()'

iommu_device_use_default_domain() reads better. And add some comments
to link "default domain" with "DMA API". Thanks!

> 
> Jason
> 

Best regards,
baolu