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: <20241104130011.GD35848@ziepe.ca>
Date: Mon, 4 Nov 2024 09:00:11 -0400
From: Jason Gunthorpe <jgg@...pe.ca>
To: "Gowans, James" <jgowans@...zon.com>
Cc: "jacob.pan@...ux.microsoft.com" <jacob.pan@...ux.microsoft.com>,
	"yi.l.liu@...el.com" <yi.l.liu@...el.com>,
	"jinankjain@...ux.microsoft.com" <jinankjain@...ux.microsoft.com>,
	"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>,
	"ssengar@...ux.microsoft.com" <ssengar@...ux.microsoft.com>,
	"joro@...tes.org" <joro@...tes.org>,
	"will@...nel.org" <will@...nel.org>,
	"Graf (AWS), Alexander" <graf@...zon.de>,
	"steven.sistare@...cle.com" <steven.sistare@...cle.com>
Subject: Re: [RFC PATCH 05/13] iommufd: Serialise persisted iommufds and ioas

On Sat, Nov 02, 2024 at 10:22:54AM +0000, Gowans, James wrote:

> Yes, I think the guidance was to bind a device to iommufd in noiommu
> mode. It does seem a bit weird to use iommufd with noiommu, but we
> agreed it's the best/simplest way to get the functionality. 

noiommu should still have an ioas and still have kernel managed page
pinning.

My remark to bring it to iommufd was to also make it a fully
architected feature and stop relying on mprotect and /proc/ tricks.

> Then as you suggest below the IOMMUFD_OBJ_DEVICE would be serialised
> too in some way, probably by iommufd telling the PCI layer that this
> device must be persistent and hence not to re-probe it on kexec.

Presumably VFIO would be doing some/most of this part since it is the
driver that will be binding?

> It's all a bit hand wavy at the moment, but something along those lines
> probably makes sense. I need to work on rev2 of this RFC as per Jason's
> feedback in the other thread. Rev2 will make the restore path more
> userspace driven, with fresh iommufd and pgtables objects being created
> and then atomically swapped over too. I'll also get the PCI layer
> involved with rev2. Once that's out (it'll be a few weeks as I'm on
> leave) then let's take a look at how the noiommu device persistence case
> would fit in.

In a certain sense it would be nice to see the noiommu flow as it
breaks apart the problem into the first dependency:

 How to get the device handed across the kexec and safely land back in
 VFIO, and only VFIO's hands.

Preserving the iommu HW configuration is an incremental step built on
that base line.

Also, FWIW, this needs to follow good open source practices - we need
an open userspace for the feature and the kernel stuff should be
merged in a logical order.

Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ