linux-kernel - Re: [PATCH 00/10] Introduce guestmemfs: persistent in-memory filesystem

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: <20240805232908.GD676757@ziepe.ca>
Date: Mon, 5 Aug 2024 20:29:08 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Jan Kara <jack@...e.cz>
Cc: James Gowans <jgowans@...zon.com>, linux-kernel@...r.kernel.org,
	Sean Christopherson <seanjc@...gle.com>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Steve Sistare <steven.sistare@...cle.com>,
	Christian Brauner <brauner@...nel.org>,
	Anthony Yznaga <anthony.yznaga@...cle.com>,
	Mike Rapoport <rppt@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-fsdevel@...r.kernel.org,
	Usama Arif <usama.arif@...edance.com>, kvm@...r.kernel.org,
	Alexander Graf <graf@...zon.com>,
	David Woodhouse <dwmw@...zon.co.uk>,
	Paul Durrant <pdurrant@...zon.co.uk>,
	Nicolas Saenz Julienne <nsaenz@...zon.es>,
	Muchun Song <muchun.song@...ux.dev>
Subject: Re: [PATCH 00/10] Introduce guestmemfs: persistent in-memory
 filesystem

On Mon, Aug 05, 2024 at 10:01:51PM +0200, Jan Kara wrote:

> > 4. Device assignment: being able to use guestmemfs memory for
> > VFIO/iommufd mappings, and allow those mappings to survive and continue
> > to be used across kexec.

That's a fun one. Proposals for that will be very interesting!

> To me the basic functionality resembles a lot hugetlbfs. Now I know very
> little details about hugetlbfs so I've added relevant folks to CC. Have you
> considered to extend hugetlbfs with the functionality you need (such as
> preservation across kexec) instead of implementing completely new filesystem?

In mm circles we've broadly been talking about splitting the "memory
provider" part out of hugetlbfs into its own layer. This would include
the carving out of kernel memory at boot and organizing it by page
size to allow huge ptes.

It would make alot of sense to have only one carve out mechanism, and
several consumers - hugetlbfs, the new private guestmemfd, this thing,
for example.

Jason