linux-kernel - Re: [PATCH v1 15/16] iommu/tegra241-cmdqv: Add user-space use support

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: <20250423115551.GC1648741@nvidia.com>
Date: Wed, 23 Apr 2025 08:55:51 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: "Tian, Kevin" <kevin.tian@...el.com>
Cc: Nicolin Chen <nicolinc@...dia.com>, "corbet@....net" <corbet@....net>,
	"will@...nel.org" <will@...nel.org>,
	"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>,
	"praan@...gle.com" <praan@...gle.com>,
	"nathan@...nel.org" <nathan@...nel.org>,
	"peterz@...radead.org" <peterz@...radead.org>,
	"Liu, Yi L" <yi.l.liu@...el.com>,
	"jsnitsel@...hat.com" <jsnitsel@...hat.com>,
	"mshavit@...gle.com" <mshavit@...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>
Subject: Re: [PATCH v1 15/16] iommu/tegra241-cmdqv: Add user-space use support

On Wed, Apr 23, 2025 at 08:05:49AM +0000, Tian, Kevin wrote:

> It's not a good idea having the kernel trust the VMM. 

It certainly shouldn't trust it, but it can validate the VMM's choice
and generate a failure if it isn't good.

> Also I'm not
> sure the contiguity is guaranteed all the time with huge page
> (e.g. if just using THP).

If things are aligned then the contiguity will work out. Ie a 64K
aligned allocation on a 2M GPA is fine. I don't think there are
edge cases where a GPA will be fragmented. It does rely on the VMM
always getting some kind of huge page and then pinning it in iommufd.

IMHO this is bad HW design, but it is what it is..

> btw does smmu only read the cmdq or also update some fields
> in the queue? If the latter, then it also brings a security hole 
> as a malicious  VMM could violate the contiguity requirement
> to instruct the smmu to touch pages which don't belong to 
> it...

This really must be prevented. I haven't looked closely here, but the
GPA -> PA mapping should go through the IOAS and that should generate
a page list and that should be validated for contiguity.

It also needs to act like a mdev and lock down the part of the IOAS
that provides that memory so the pin can't be released and UAF things.

Jason