linux-kernel - Re: [PATCH v2 3/7] iommu: Make iommu_dma_prepare

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: <634c60ea-fec3-43ad-923a-cf9ba5e76065@arm.com>
Date: Thu, 27 Feb 2025 11:21:28 +0000
From: Robin Murphy <robin.murphy@....com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: Nicolin Chen <nicolinc@...dia.com>, kevin.tian@...el.com,
 tglx@...utronix.de, maz@...nel.org, joro@...tes.org, will@...nel.org,
 shuah@...nel.org, iommu@...ts.linux.dev, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-kselftest@...r.kernel.org,
 eric.auger@...hat.com, baolu.lu@...ux.intel.com, yi.l.liu@...el.com,
 yury.norov@...il.com, jacob.pan@...ux.microsoft.com, patches@...ts.linux.dev
Subject: Re: [PATCH v2 3/7] iommu: Make iommu_dma_prepare_msi() into a generic
 operation

On 2025-02-21 4:44 pm, Jason Gunthorpe wrote:
> On Fri, Feb 21, 2025 at 03:39:45PM +0000, Robin Murphy wrote:
>> Yuck. Realistically we are going to have no more than two different
>> implementations of this; a fiddly callback interface seems overkill. All we
>> should need in the domain is a simple indicator of *which* MSI translation
>> scheme is in use (if it can't be squeezed into the domain type itself), then
>> iommu_dma_prepare_msi() can simply dispatch between iommu-dma and IOMMUFD
>> based on that, and then it's easy to solve all the other fragility issues
>> too.
> 
> That would make module dependency problems, we have so far avoided
> having the core kernel hard depend on iommufd.

It wouldn't need a hard dependency, it's easy to have a trivial built-in 
stub function which becomes valid once the module loads - you literally 
have the iommufd_driver infrastructure for precisely that sort of thing 
already. All I'm saying is to hide the callback detail in the IOMMUFD 
code because being IOMMUFD modular is unique to IOMMUFD and not the rest 
of the core code's problem.

And frankly otherwise, what even is the benefit of moving the 
iova_cookie pointer into the union if we have to replace it with another 
whole pointer to make it work? This is just adding more code and more 
complexity in in order to make struct iommu_domain... the same size it 
already is :/

Thanks,
Robin.