linux-kernel - Re: [RFC PATCH 05/13] iommufd: Serialise persisted iommufds and ioas

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: <20241007151633.GO2456194@ziepe.ca>
Date: Mon, 7 Oct 2024 12:16:33 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: "Gowans, James" <jgowans@...zon.com>
Cc: "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"rppt@...nel.org" <rppt@...nel.org>, "kw@...ux.com" <kw@...ux.com>,
	"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
	"madvenka@...ux.microsoft.com" <madvenka@...ux.microsoft.com>,
	"anthony.yznaga@...cle.com" <anthony.yznaga@...cle.com>,
	"robin.murphy@....com" <robin.murphy@....com>,
	"baolu.lu@...ux.intel.com" <baolu.lu@...ux.intel.com>,
	"nh-open-source@...zon.com" <nh-open-source@...zon.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"seanjc@...gle.com" <seanjc@...gle.com>,
	"Saenz Julienne, Nicolas" <nsaenz@...zon.es>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>,
	"kevin.tian@...el.com" <kevin.tian@...el.com>,
	"dwmw2@...radead.org" <dwmw2@...radead.org>,
	"steven.sistare@...cle.com" <steven.sistare@...cle.com>,
	"Graf (AWS), Alexander" <graf@...zon.de>,
	"will@...nel.org" <will@...nel.org>,
	"joro@...tes.org" <joro@...tes.org>
Subject: Re: [RFC PATCH 05/13] iommufd: Serialise persisted iommufds and ioas

On Mon, Oct 07, 2024 at 08:39:53AM +0000, Gowans, James wrote:

> 2. Get userspace to do the work: userspace needs to re-do the ioctls
> after kexec to reconstruct the objects. My main issue with this approach
> is that the kernel needs to do some sort of trust but verify approach to
> ensure that userspace constructs everything the same way after kexec as
> it was before kexec. We don't want to end up in a state where the
> iommufd objects don't match the persisted page tables.

I think the verification is not so bad, it is just extracting the
physical addresses from the IOAS and comparing to what is stored in
the iommu_domain. If they don't match then the domain can't be adopted
to the IOAS.

We actually don't care about anything else, if userspace creates
different objects with different parameters who cares? All that
matters is that the radix tree contains the same expected information.

> What do you think of this 3rd approach? I can try to sketch it out and
> send another RFC if you think it sounds reasonable.

I think it is the same problem, just in a more maintainable
wrapper. You still have to serialize lots and lots of different
objects and their relationships.

> > Ie "recover" a HWPT from a KHO on a manually created a IOAS with the
> > right "memfd" for the backing storage. Then the recovery can just
> > validate that things are correct and adopt the iommu_domain as the
> > hwpt.
>
> This sounds more like option 2 where we expect userspace to re-drive the
> ioctls, but verify that they have corresponding payloads as before kexec
> so that iommufd objects are consistent with persisted page tables.

Yes

> If the kernel is doing verification wouldn't it be better for the kernel
> to do the ioctl work itself and give the resulting objects to
> userspace?

No :)

It is so much easier to validate the IOPTEs in a radix tree.

At the very worst you just create a HWPT and iommu_domain for
validation, do validation and then throw it away. Compare for two
radix trees is about 50 lines in generic pt, I have it already.

Jason