linux-kernel - Re: [RFC PATCH 26/39] KVM: guest_memfd: Track faultability within a struct kvm_gmem

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: <ZxFD3kYfKY0b-qFz@x1n>
Date: Thu, 17 Oct 2024 13:05:34 -0400
From: Peter Xu <peterx@...hat.com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: David Hildenbrand <david@...hat.com>,
	Ackerley Tng <ackerleytng@...gle.com>, tabba@...gle.com,
	quic_eberman@...cinc.com, roypat@...zon.co.uk, rientjes@...gle.com,
	fvdl@...gle.com, jthoughton@...gle.com, seanjc@...gle.com,
	pbonzini@...hat.com, zhiquan1.li@...el.com, fan.du@...el.com,
	jun.miao@...el.com, isaku.yamahata@...el.com, muchun.song@...ux.dev,
	erdemaktas@...gle.com, vannapurve@...gle.com, qperret@...gle.com,
	jhubbard@...dia.com, willy@...radead.org, shuah@...nel.org,
	brauner@...nel.org, bfoster@...hat.com, kent.overstreet@...ux.dev,
	pvorel@...e.cz, rppt@...nel.org, richard.weiyang@...il.com,
	anup@...infault.org, haibo1.xu@...el.com, ajones@...tanamicro.com,
	vkuznets@...hat.com, maciej.wieczor-retman@...el.com,
	pgonda@...gle.com, oliver.upton@...ux.dev,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	kvm@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [RFC PATCH 26/39] KVM: guest_memfd: Track faultability within a
 struct kvm_gmem_private

On Thu, Oct 17, 2024 at 01:47:13PM -0300, Jason Gunthorpe wrote:
> On Thu, Oct 17, 2024 at 10:58:29AM -0400, Peter Xu wrote:
> 
> > My question was more torwards whether gmemfd could still expose the
> > possibility to be used in VA forms to other modules that may not support
> > fd+offsets yet.
> 
> I keep hearing they don't want to support page pinning on a guestmemfd
> mapping, so VA based paths could not work.

Do you remember the reasoning of it?  Is it because CoCo still needs to
have a bounded time window to convert from shared back to private?  If so,
maybe that's a non-issue for non-CoCo, where the VM object / gmemfd object
(when created) can have a flag marking that it's always shared and can
never be converted to private for any page within.

So how would VFIO's DMA work even with iommufd if pages cannot be pinned?
Is some form of bounce buffering required, then?

It sounds like if so there'll be a lot of use cases that won't work with
current infrastructure..

> 
> > I think as long as we can provide gmemfd VMAs like what this series
> > provides, it sounds possible to reuse the old VA interfaces before the CoCo
> > interfaces are ready, so that people can already start leveraging gmemfd
> > backing pages.
> 
> And you definitely can't get the private pages out of the VA interface
> because all the VMA PTEs of private pages are non-present by definition.

It's the same as "not present" if the fault() gets a SIGBUS always for
private pages, IIUC.

My prior references to "VA ranges" are mostly only for shared / faultable
pages. And they'll get zapped too when requested to be converted from
shared -> private, aka, always not present for private.

> 
> Hence, you must use the FD for a lot of use cases here.

Thanks,

-- 
Peter Xu