linux-kernel - Re: [PATCH 05/10] guestmemfs: add file mmap callback

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: <20241031160635.GA35848@ziepe.ca>
Date: Thu, 31 Oct 2024 13:06:35 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: "Gowans, James" <jgowans@...zon.com>
Cc: "quic_eberman@...cinc.com" <quic_eberman@...cinc.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"rppt@...nel.org" <rppt@...nel.org>,
	"brauner@...nel.org" <brauner@...nel.org>,
	"Graf (AWS), Alexander" <graf@...zon.de>,
	"anthony.yznaga@...cle.com" <anthony.yznaga@...cle.com>,
	"steven.sistare@...cle.com" <steven.sistare@...cle.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"seanjc@...gle.com" <seanjc@...gle.com>,
	"Woodhouse, David" <dwmw@...zon.co.uk>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"Saenz Julienne, Nicolas" <nsaenz@...zon.es>,
	"Durrant, Paul" <pdurrant@...zon.co.uk>,
	"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
	"jack@...e.cz" <jack@...e.cz>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"usama.arif@...edance.com" <usama.arif@...edance.com>
Subject: Re: [PATCH 05/10] guestmemfs: add file mmap callback

On Thu, Oct 31, 2024 at 03:30:59PM +0000, Gowans, James wrote:
> On Tue, 2024-10-29 at 16:05 -0700, Elliot Berman wrote:
> > On Mon, Aug 05, 2024 at 11:32:40AM +0200, James Gowans wrote:
> > > Make the file data usable to userspace by adding mmap. That's all that
> > > QEMU needs for guest RAM, so that's all be bother implementing for now.
> > > 
> > > When mmaping the file the VMA is marked as PFNMAP to indicate that there
> > > are no struct pages for the memory in this VMA. Remap_pfn_range() is
> > > used to actually populate the page tables. All PTEs are pre-faulted into
> > > the pgtables at mmap time so that the pgtables are usable when this
> > > virtual address range is given to VFIO's MAP_DMA.
> > 
> > Thanks for sending this out! I'm going through the series with the
> > intention to see how it might fit within the existing guest_memfd work
> > for pKVM/CoCo/Gunyah.
> > 
> > It might've been mentioned in the MM alignment session -- you might be
> > interested to join the guest_memfd bi-weekly call to see how we are
> > overlapping [1].
> > 
> > [1]: https://lore.kernel.org/kvm/ae794891-fe69-411a-b82e-6963b594a62a@redhat.com/T/
> 
> Hi Elliot, yes, I think that there is a lot more overlap with
> guest_memfd necessary here. The idea was to extend guestmemfs at some
> point to have a guest_memfd style interface, but it was pointed out at
> the MM alignment call that doing so would require guestmemfs to
> duplicate the API surface of guest_memfd. This is undesirable. Better
> would be to have persistence implemented as a custom allocator behind a
> normal guest_memfd. I'm not too sure how this would be actually done in
> practice, specifically: 
> - how the persistent pool would be defined
> - how it would be supplied to guest_memfd
> - how the guest_memfds would be re-discovered after kexec
> But assuming we can figure out some way to do this, I think it's a
> better way to go.

I think the filesystem interface seemed reasonable, you just want
open() on the filesystem to return back a normal guest_memfd and
re-use all of that code to implement it.

When opened through the filesystem guest_memfd would get hooked by the
KHO stuff to manage its memory, somehow.

Really KHO just needs to keep track of the addresess in the
guest_memfd when it serializes, right? So maybe all it needs is a way
to freeze the guest_memfd so it's memory map doesn't change anymore,
then a way to extract the addresses from it for serialization?

Jason