linux-kernel - Re: [RFC PATCH 03/13] iommu/intel: zap context table entries on kexec

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241003132725.GA2456194@ziepe.ca>
Date: Thu, 3 Oct 2024 10:27:25 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: James Gowans <jgowans@...zon.com>
Cc: linux-kernel@...r.kernel.org, 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>
Subject: Re: [RFC PATCH 03/13] iommu/intel: zap context table entries on kexec

On Mon, Sep 16, 2024 at 01:30:52PM +0200, James Gowans wrote:
> Instead of fully shutting down the IOMMU on kexec, rather zap context
> table entries for devices. This is the initial step to be able to
> persist some domains. Once a struct iommu_domain can be marked
> persistent then those persistent domains will be skipped when doing the
> IOMMU shut down.
> ---
>  drivers/iommu/intel/dmar.c  |  1 +
>  drivers/iommu/intel/iommu.c | 34 ++++++++++++++++++++++++++++++----
>  drivers/iommu/intel/iommu.h |  2 ++
>  3 files changed, 33 insertions(+), 4 deletions(-)

We should probably try to avoid doing this kind of stuff in
drivers. The core code can generically ask drivers to attach a
BLOCKING domain as part of the kexec sequence and the core code can
then decide which devices should be held over.

There is also some complexity here around RMRs, we can't always apply
a blocking domain... Not sure what you'd do in those cases.

IIRC we already do something like this with the bus master enable on
the PCI side?? At least, if the kernel is deciding to block DMA when
the IOMMU is on it should do it consistently and inhibit the PCI
device as well.

Jason