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

> From: Nicolin Chen <nicolinc@...dia.com>
> Sent: Tuesday, May 6, 2025 4:08 AM
> 
> 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?
> 

According to [1]:

" The mmap() function adds an extra reference to the file associated
with the file descriptor fildes which is not removed by a subsequent
close() on that file descriptor. This reference is removed when there
are no more mappings to the file. "

what Nicoline proposed in v3 adopts a similar policy. So it kind of
makes sense to me, except that we should not return -EBUSY in 
vIOMMU destroy ioctl. Instead, just decrement the reference.

[1] https://pubs.opengroup.org/onlinepubs/7908799/xsh/mmap.html