linux-kernel - Re: [RFC PATCH 27/39] KVM: guest_memfd: Allow mmapping guest

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: <Z+y4E3tcOCOJxCiS@yzhao56-desk.sh.intel.com>
Date: Wed, 2 Apr 2025 12:07:47 +0800
From: Yan Zhao <yan.y.zhao@...el.com>
To: Ackerley Tng <ackerleytng@...gle.com>
CC: <tabba@...gle.com>, <quic_eberman@...cinc.com>, <roypat@...zon.co.uk>,
	<jgg@...dia.com>, <peterx@...hat.com>, <david@...hat.com>,
	<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>, <mike.kravetz@...cle.com>, <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>, <linux-fsdevel@...ck.org>,
	<rick.p.edgecombe@...el.com>
Subject: Re: [RFC PATCH 27/39] KVM: guest_memfd: Allow mmapping guest_memfd
 files

On Tue, Sep 10, 2024 at 11:43:58PM +0000, Ackerley Tng wrote:
> guest_memfd files can always be mmap()ed to userspace, but
> faultability is controlled by an attribute on the inode.
> 
> Co-developed-by: Fuad Tabba <tabba@...gle.com>
> Signed-off-by: Fuad Tabba <tabba@...gle.com>
> Co-developed-by: Ackerley Tng <ackerleytng@...gle.com>
> Signed-off-by: Ackerley Tng <ackerleytng@...gle.com>
> 
> ---
>  virt/kvm/guest_memfd.c | 46 ++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 44 insertions(+), 2 deletions(-)
> 
> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> index b603518f7b62..fc2483e35876 100644
> --- a/virt/kvm/guest_memfd.c
> +++ b/virt/kvm/guest_memfd.c
> @@ -781,7 +781,8 @@ static long kvm_gmem_punch_hole(struct inode *inode, loff_t offset, loff_t len)
>  {
Hi Ackerley,

If userspace mmaps a guest_memfd to a VA when a GFN range is shared, it looks
that even after the GFN range has been successfully converted to private,
userspace can still call madvise(mem, size, MADV_REMOVE) on the userspace VA.
This action triggers kvm_gmem_punch_hole() and kvm_gmem_invalidate_begin(),
which can zap the private GFNs in the EPT.

Is this behavior intended for in-place conversion, and could it potentially lead
to private GFN ranges being accidentally zapped from the EPT?

Apologies if I missed any related discussions on this topic.

Thanks
Yan

>  	struct list_head *gmem_list = &inode->i_mapping->i_private_list;
>  	pgoff_t start = offset >> PAGE_SHIFT;
> -	pgoff_t end = (offset + len) >> PAGE_SHIFT;
> +	pgoff_t nr = len >> PAGE_SHIFT;
> +	pgoff_t end = start + nr;
>  	struct kvm_gmem *gmem;
>  
>  	/*
> @@ -790,6 +791,9 @@ static long kvm_gmem_punch_hole(struct inode *inode, loff_t offset, loff_t len)
>  	 */
>  	filemap_invalidate_lock(inode->i_mapping);
>  
> +	/* TODO: Check if even_cows should be 0 or 1 */
> +	unmap_mapping_range(inode->i_mapping, start, len, 0);
> +
>  	list_for_each_entry(gmem, gmem_list, entry)
>  		kvm_gmem_invalidate_begin(gmem, start, end);
>