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: <20241016152047.2a604f08@DESKTOP-0403QTC.>
Date: Wed, 16 Oct 2024 15:20:47 -0700
From: Jacob Pan <jacob.pan@...ux.microsoft.com>
To: James Gowans <jgowans@...zon.com>
Cc: <linux-kernel@...r.kernel.org>, Jason Gunthorpe <jgg@...pe.ca>, Kevin
 Tian <kevin.tian@...el.com>, "Joerg Roedel" <joro@...tes.org>, Krzysztof
 Wilczyński <kw@...ux.com>, Will Deacon <will@...nel.org>,
 Robin Murphy <robin.murphy@....com>, Mike Rapoport <rppt@...nel.org>,
 "Madhavan T. Venkataraman" <madvenka@...ux.microsoft.com>,
 <iommu@...ts.linux.dev>, "Sean Christopherson" <seanjc@...gle.com>, Paolo
 Bonzini <pbonzini@...hat.com>, <kvm@...r.kernel.org>, David Woodhouse
 <dwmw2@...radead.org>, Lu Baolu <baolu.lu@...ux.intel.com>, Alexander Graf
 <graf@...zon.de>, <anthony.yznaga@...cle.com>, <steven.sistare@...cle.com>,
 <nh-open-source@...zon.com>, "Saenz Julienne, Nicolas" <nsaenz@...zon.es>,
 jacob.pan@...ux.microsoft.com
Subject: Re: [RFC PATCH 05/13] iommufd: Serialise persisted iommufds and
 ioas

Hi James,

On Mon, 16 Sep 2024 13:30:54 +0200
James Gowans <jgowans@...zon.com> wrote:

> +static int serialise_iommufd(void *fdt, struct iommufd_ctx *ictx)
> +{
> +	int err = 0;
> +	char name[24];
> +	struct iommufd_object *obj;
> +	unsigned long obj_idx;
> +
> +	snprintf(name, sizeof(name), "%lu", ictx->persistent_id);
> +	err |= fdt_begin_node(fdt, name);
> +	err |= fdt_begin_node(fdt, "ioases");
> +	xa_for_each(&ictx->objects, obj_idx, obj) {
> +		struct iommufd_ioas *ioas;
> +		struct iopt_area *area;
> +		int area_idx = 0;
> +
> +		if (obj->type != IOMMUFD_OBJ_IOAS)
> +			continue;
I was wondering how device state persistency is managed here. Is it
correct to assume that all devices bound to an iommufd context should
be persistent? If so, should we be serializing IOMMUFD_OBJ_DEVICE as
well?

I'm considering this from the perspective of user mode drivers,
including those that use noiommu mode (need to be added to iommufd
cdev). In this scenario, we only need to maintain the device states
persistently without IOAS.