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: <aBwp0JviKskqbPXz@nvidia.com>
Date: Wed, 7 May 2025 20:49:36 -0700
From: Nicolin Chen <nicolinc@...dia.com>
To: Jason Gunthorpe <jgg@...dia.com>
CC: Pranjal Shrivastava <praan@...gle.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>, <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 Wed, May 07, 2025 at 07:08:09PM -0300, Jason Gunthorpe wrote:
> On Wed, May 07, 2025 at 02:09:31PM -0700, Nicolin Chen wrote:
> > I have another question: while I don't think my code is handling
> > this well either, how should we validate the input address is an
> > allowed one?
> 
> The pgoff to mmap? If it isn't in the maple tree it is not allowed, if
> it isn't at the start of range it is not allowed, if the size is not
> exactly the same as the range it is not allowed.

Kevin suggested to allow a partial mmap, i.e allow the size to be
smaller than what the cookie describes. Yet, surely the mmap size
should not above the allocated size.

> > Because mmap() is per ictx, i.e. it's a global translation table.
> 
> It's per-FD. The pgoff number space is per-fd calling mmap.
> 
> > So, the following might happen: let's say we have two vIOMMUs in
> > the same ictx. Either vIOMMU has reported a cookie to index the
> > mtree for the real PFN range: call them PFN_RANGE0 (for vIOMMU0)
> > and PFN_RANGE1 (for vIOMMU1). What if a buggy VMM inverted these
> > cookies between the two vIOMMUs, so it would end up with vIOMMU0
> > accessing PFN_RANGE1?
> 
> Oh well. That is too buggy for the kernel to do anything about. The
> mmap cookie comes out of the VIOMMU_ALLOC call and goes back into the
> mmap() call, if you mess it up or mix up the pointers then too bad.
> 
> But if two VMMs are doing this then they each have their own iommufd
> and their own private numberspace and VMM A's VIOMMU cannot be mapped
> through VMM B's iommufd FD.

I was concerned about the one VM case, which uses the same ictx
and thus the same mtree.

So, an address translation table (like IOMMU) has a separate AS
(i.e. iommu_domain) for a device. This can limit the device from
accessing other device's memory. And it would be ideal for this
mmap interface (a translation site) to do the same.

However, given that it is a global translation table, we don't
have many choices for the isolation, but only (as your remarks):
1) Check if the given vm_pgoff is in the mtree
2) Check if the given length doesn't cross the real PFN range

Thanks
Nicolin