linux-kernel - Re: [PATCH v2 13/22] iommufd: Add mmap interface

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: <20250506125425.GX2260709@nvidia.com>
Date: Tue, 6 May 2025 09:54:25 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Nicolin Chen <nicolinc@...dia.com>
Cc: Baolu Lu <baolu.lu@...ux.intel.com>, kevin.tian@...el.com,
	corbet@....net, will@...nel.org, bagasdotme@...il.com,
	robin.murphy@....com, joro@...tes.org, thierry.reding@...il.com,
	vdumpa@...dia.com, jonathanh@...dia.com, shuah@...nel.org,
	jsnitsel@...hat.com, nathan@...nel.org, peterz@...radead.org,
	yi.l.liu@...el.com, mshavit@...gle.com, praan@...gle.com,
	zhangzekun11@...wei.com, iommu@...ts.linux.dev,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-tegra@...r.kernel.org,
	linux-kselftest@...r.kernel.org, patches@...ts.linux.dev,
	mochs@...dia.com, alok.a.tiwari@...cle.com, vasant.hegde@....com
Subject: Re: [PATCH v2 13/22] iommufd: Add mmap interface

On Mon, May 05, 2025 at 01:07:34PM -0700, Nicolin Chen wrote:
> On Mon, May 05, 2025 at 02:28:13PM -0300, Jason Gunthorpe wrote:
> > On Mon, May 05, 2025 at 10:21:03AM -0700, Nicolin Chen wrote:
> > > > > > +void iommufd_ctx_free_mmap(struct iommufd_ctx *ictx, unsigned long immap_id)
> > > > > > +{
> > > > > > +	kfree(mtree_erase(&ictx->mt_mmap, immap_id >> PAGE_SHIFT));
> > > > > 
> > > > > MMIO lifecycle question: what happens if a region is removed from the
> > > > > maple tree (and is therefore no longer mappable), but is still mapped
> > > > > and in use by userspace?
> > > > 
> > > > I think we should probably zap it and make any existing VMAs
> > > > SIGBUS... Otherwise it is hard to reason about from the kernel side
> > > 
> > > I added in v3 a pair of open/close op that would refcount the
> > > vIOMMU object (owner of the mmap region). This would EBUSY the
> > > vIOMMU destroy ioctl that would call this function.
> > 
> > That's no good, we can't have VMAs prevent cleaning up iommufd
> 
> Hmm, would you please elaborate why?

It would create weird dependencies in the kernel that become hard to
manage. If we really need to unplug the PFNs behind the VMA for some
reason then we should always allow that to progress. Requiring the VMA
to be unmapped first is not great.

> > objects, the right thing is to zap it with invalidate_mapping_range()
> 
> Also, I can't find much info about invalidate_mapping_range(). Is
> it a user space call?

unmap_mapping_range(), see how VFIO uses it.
 
> I do see a few drivers defining a fault op in vm_operations_struct,
> where VM_FAULT_SIGBUS is returned when there is page backing up the
> VMAs. Is it what we need here?

Probably as well

Jason