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: <aBp28sjZpPfDUfYr@nvidia.com>
Date: Tue, 6 May 2025 13:54:10 -0700
From: Nicolin Chen <nicolinc@...dia.com>
To: Jason Gunthorpe <jgg@...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 Tue, May 06, 2025 at 09:54:25AM -0300, Jason Gunthorpe wrote:
> 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.

OK.

Now I start to think about the FD situation: either a fault queue or
an eventq returns an FD and holds a refcount on the event object. So
the event object can't be destroyed unless the FD is released first.
Are we doing it incorrectly here?

> > > 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 see! It just needs to call that function when we remove the mmap
for a vIOMMU destroy().

> > 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

Once the vma is unmapped, any further access would trigger a fault,
right? That's how it works.

I see do_fault() report a VM_FAULT_SIGBUS, when !vma->vm_ops->fault.
So, perhaps we don't need an iommufd fault op at this moment.

Thanks
Nicolin