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] [day] [month] [year] [list]

Message-ID: <20241009122830.GF762027@ziepe.ca>
Date: Wed, 9 Oct 2024 09:28:30 -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>,
	"maz@...nel.org" <maz@...nel.org>
Subject: Re: [RFC PATCH 05/13] iommufd: Serialise persisted iommufds and ioas

On Wed, Oct 09, 2024 at 11:44:30AM +0000, Gowans, James wrote:

> Okay, but in general this still means that the page tables must have
> exactly the same translations if we try to switch from one set to
> another. If it is possible to change translations then translation table
> entries could be created at different granularity (PTE, PMD, PUD) level
> which would violate this requirement. 

Yes, but we strive to make page tables consistently and it isn't that
often that we get new features that would chang the layout (contig bit
for instance). I'd suggest in these cases you'd add some creation flag
to the HWPT that can inhibit the new feature and your VMM will deal
with it.

Or you sweep it and manually split/join to deal with BBM < level
2. Generic pt will have code to do all of this so it is not that bad.

If this little issue already scares you then I don't think I want to
see you serialize anything more complex, there are endless scenarios
for compatibility problems :\

> It's also possible for different IOMMU driver versions to set up the the
> same translations, but at different page table levels. Perhaps an older
> version did not coalesce come PTEs, but a newer version does coalesce.
> Would the same translations but at a different size violate BBM?

Yes, that is the only thing that violates BBM.

> If we say that to be safe/correct in the general case then it is
> necessary for the translations to be *exactly* the same before and after
> kexec, is there any benefit to building new translation tables and
> switching to them? We may as well continue to use the exact same page
> tables and construct iommufd objects (IOAS, etc) to match.

The benifit is principally that you did all the machinery to get up to
that point, including re-pinning and so forth all the memory, instead
of trying to magically recover that additional state.

This is the philosophy that you replay instead of de-serialize, so you
have to replay into a page table at some level to make that work.

> There is also a performance consideration here: when doing live update
> every millisecond of down time matters. I'm not sure if this iommufd re-
> initialisation will end up being in the hot path of things that need to
> be done before the VM can start running again. 

As we talked about in the session, your KVM can start running
immediately, you don't need iommufd to be fully setup.

You only need iommufd fully working again if you intend to do certain
operations, like memory hotplug or something that requires an address
map change. So you can operate in a degraded state that is largely
invisible to the guest while recovering this stuff. It shouldn't be on
your critical path.

> then it would be useful to avoid rebuilding identical tables. Maybe it
> ends up being in the "warm" path - the VM can start running but will
> sleep if taking a page fault before IOMMUFD is re-initalised...

I didn't think you'd support page faults? There are bigger issues here
if you expect to have a vIOMMU in the guest.

Jason