linux-kernel - Re: [RFC PATCH v2 04/51] KVM: guest_memfd: Introduce KVM_GMEM_CONVERT

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: <20250702141321.GC904431@ziepe.ca>
Date: Wed, 2 Jul 2025 11:13:21 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Vishal Annapurve <vannapurve@...gle.com>
Cc: Yan Zhao <yan.y.zhao@...el.com>, Alexey Kardashevskiy <aik@....com>,
	Fuad Tabba <tabba@...gle.com>,
	Ackerley Tng <ackerleytng@...gle.com>, kvm@...r.kernel.org,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org, x86@...nel.org,
	linux-fsdevel@...r.kernel.org, ajones@...tanamicro.com,
	akpm@...ux-foundation.org, amoorthy@...gle.com,
	anthony.yznaga@...cle.com, anup@...infault.org,
	aou@...s.berkeley.edu, bfoster@...hat.com,
	binbin.wu@...ux.intel.com, brauner@...nel.org,
	catalin.marinas@....com, chao.p.peng@...el.com,
	chenhuacai@...nel.org, dave.hansen@...el.com, david@...hat.com,
	dmatlack@...gle.com, dwmw@...zon.co.uk, erdemaktas@...gle.com,
	fan.du@...el.com, fvdl@...gle.com, graf@...zon.com,
	haibo1.xu@...el.com, hch@...radead.org, hughd@...gle.com,
	ira.weiny@...el.com, isaku.yamahata@...el.com, jack@...e.cz,
	james.morse@....com, jarkko@...nel.org, jgowans@...zon.com,
	jhubbard@...dia.com, jroedel@...e.de, jthoughton@...gle.com,
	jun.miao@...el.com, kai.huang@...el.com, keirf@...gle.com,
	kent.overstreet@...ux.dev, kirill.shutemov@...el.com,
	liam.merwick@...cle.com, maciej.wieczor-retman@...el.com,
	mail@...iej.szmigiero.name, maz@...nel.org, mic@...ikod.net,
	michael.roth@....com, mpe@...erman.id.au, muchun.song@...ux.dev,
	nikunj@....com, nsaenz@...zon.es, oliver.upton@...ux.dev,
	palmer@...belt.com, pankaj.gupta@....com, paul.walmsley@...ive.com,
	pbonzini@...hat.com, pdurrant@...zon.co.uk, peterx@...hat.com,
	pgonda@...gle.com, pvorel@...e.cz, qperret@...gle.com,
	quic_cvanscha@...cinc.com, quic_eberman@...cinc.com,
	quic_mnalajal@...cinc.com, quic_pderrin@...cinc.com,
	quic_pheragu@...cinc.com, quic_svaddagi@...cinc.com,
	quic_tsoni@...cinc.com, richard.weiyang@...il.com,
	rick.p.edgecombe@...el.com, rientjes@...gle.com,
	roypat@...zon.co.uk, rppt@...nel.org, seanjc@...gle.com,
	shuah@...nel.org, steven.price@....com, steven.sistare@...cle.com,
	suzuki.poulose@....com, thomas.lendacky@....com,
	usama.arif@...edance.com, vbabka@...e.cz, viro@...iv.linux.org.uk,
	vkuznets@...hat.com, wei.w.wang@...el.com, will@...nel.org,
	willy@...radead.org, xiaoyao.li@...el.com, yilun.xu@...el.com,
	yuzenghui@...wei.com, zhiquan1.li@...el.com
Subject: Re: [RFC PATCH v2 04/51] KVM: guest_memfd: Introduce
 KVM_GMEM_CONVERT_SHARED/PRIVATE ioctls

On Wed, Jul 02, 2025 at 06:54:10AM -0700, Vishal Annapurve wrote:
> On Wed, Jul 2, 2025 at 1:38 AM Yan Zhao <yan.y.zhao@...el.com> wrote:
> >
> > On Tue, Jun 24, 2025 at 07:10:38AM -0700, Vishal Annapurve wrote:
> > > On Tue, Jun 24, 2025 at 6:08 AM Jason Gunthorpe <jgg@...pe.ca> wrote:
> > > >
> > > > On Tue, Jun 24, 2025 at 06:23:54PM +1000, Alexey Kardashevskiy wrote:
> > > >
> > > > > Now, I am rebasing my RFC on top of this patchset and it fails in
> > > > > kvm_gmem_has_safe_refcount() as IOMMU holds references to all these
> > > > > folios in my RFC.
> > > > >
> > > > > So what is the expected sequence here? The userspace unmaps a DMA
> > > > > page and maps it back right away, all from the userspace? The end
> > > > > result will be the exactly same which seems useless. And IOMMU TLB
> > >
> > >  As Jason described, ideally IOMMU just like KVM, should just:
> > > 1) Directly rely on guest_memfd for pinning -> no page refcounts taken
> > > by IOMMU stack
> > In TDX connect, TDX module and TDs do not trust VMM. So, it's the TDs to inform
> > TDX module about which pages are used by it for DMAs purposes.
> > So, if a page is regarded as pinned by TDs for DMA, the TDX module will fail the
> > unmap of the pages from S-EPT.

I don't see this as having much to do with iommufd.

iommufd will somehow support the T=1 iommu inside the TDX module but
it won't have an IOAS for it since the VMM does not control the
translation.

The discussion here is for the T=0 iommu which is controlled by
iommufd and does have an IOAS. It should be popoulated with all the
shared pages from the guestmemfd.

> > If IOMMU side does not increase refcount, IMHO, some way to indicate that
> > certain PFNs are used by TDs for DMA is still required, so guest_memfd can
> > reject the request before attempting the actual unmap.

This has to be delt with between the TDX module and KVM. When KVM
gives pages to become secure it may not be able to get them back..

This problem has nothing to do with iommufd.

But generally I expect that the T=1 iommu follows the S-EPT entirely
and there is no notion of pages "locked for dma". If DMA is ongoing
and a page is made non-secure then the DMA fails.

Obviously in a mode where there is a vPCI device we will need all the
pages to be pinned in the guestmemfd to prevent any kind of
migrations. Only shared/private conversions should change the page
around.

Maybe this needs to be an integral functionality in guestmemfd?

Jason