linux-kernel - Re: [RFC PATCH v1 05/37] KVM: guest_memfd: Wire up kvm_get_memory

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: <CAEvNRgEuez=JbArRf2SApLAL0usv5-Q6q=nBPOFMHrHGaKAtMw@mail.gmail.com>
Date: Wed, 28 Jan 2026 13:47:50 -0800
From: Ackerley Tng <ackerleytng@...gle.com>
To: Alexey Kardashevskiy <aik@....com>, cgroups@...r.kernel.org, kvm@...r.kernel.org, 
	linux-doc@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org, 
	linux-mm@...ck.org, linux-trace-kernel@...r.kernel.org, x86@...nel.org
Cc: akpm@...ux-foundation.org, binbin.wu@...ux.intel.com, bp@...en8.de, 
	brauner@...nel.org, chao.p.peng@...el.com, chenhuacai@...nel.org, 
	corbet@....net, dave.hansen@...el.com, dave.hansen@...ux.intel.com, 
	david@...hat.com, dmatlack@...gle.com, erdemaktas@...gle.com, 
	fan.du@...el.com, fvdl@...gle.com, haibo1.xu@...el.com, hannes@...xchg.org, 
	hch@...radead.org, hpa@...or.com, hughd@...gle.com, ira.weiny@...el.com, 
	isaku.yamahata@...el.com, jack@...e.cz, james.morse@....com, 
	jarkko@...nel.org, jgg@...pe.ca, 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, 
	liam.merwick@...cle.com, maciej.wieczor-retman@...el.com, 
	mail@...iej.szmigiero.name, maobibo@...ngson.cn, 
	mathieu.desnoyers@...icios.com, maz@...nel.org, mhiramat@...nel.org, 
	mhocko@...nel.org, mic@...ikod.net, michael.roth@....com, mingo@...hat.com, 
	mlevitsk@...hat.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, 
	peterx@...hat.com, pgonda@...gle.com, prsampat@....com, pvorel@...e.cz, 
	qperret@...gle.com, richard.weiyang@...il.com, rick.p.edgecombe@...el.com, 
	rientjes@...gle.com, rostedt@...dmis.org, roypat@...zon.co.uk, 
	rppt@...nel.org, seanjc@...gle.com, shakeel.butt@...ux.dev, shuah@...nel.org, 
	steven.price@....com, steven.sistare@...cle.com, suzuki.poulose@....com, 
	tabba@...gle.com, tglx@...utronix.de, thomas.lendacky@....com, 
	vannapurve@...gle.com, vbabka@...e.cz, viro@...iv.linux.org.uk, 
	vkuznets@...hat.com, wei.w.wang@...el.com, will@...nel.org, 
	willy@...radead.org, wyihan@...gle.com, xiaoyao.li@...el.com, 
	yan.y.zhao@...el.com, yilun.xu@...el.com, yuzenghui@...wei.com, 
	zhiquan1.li@...el.com
Subject: Re: [RFC PATCH v1 05/37] KVM: guest_memfd: Wire up
 kvm_get_memory_attributes() to per-gmem attributes

Alexey Kardashevskiy <aik@....com> writes:

>
> [...snip...]
>
>

Thanks for bringing this up!

> I am trying to make it work with TEE-IO where fd of VFIO MMIO is a dmabuf fd while the rest (guest RAM) is gmemfd. The above suggests that if there is gmemfd - then the memory attributes are handled by gmemfd which is... expected?
>

I think this is not expected.

IIUC MMIO guest physical addresses don't have an associated memslot, but
if you managed to get to that line in kvm_gmem_get_memory_attributes(),
then there is an associated memslot (slot != NULL)?

Either way, guest_memfd shouldn't store attributes for guest physical
addresses that don't belong to some guest_memfd memslot.

I think we need a broader discussion for this on where to store memory
attributes for MMIO addresses.

I think we should at least have line of sight to storing memory
attributes for MMIO addresses, in case we want to design something else,
since we're putting vm_memory_attributes on a deprecation path with this
series.

Sean, what do you think?

Alexey, shall we discuss this at either the upcoming PUCK or guest_memfd
biweekly session?

> The problem at hand is that kvm_mmu_faultin_pfn() fails at "if (fault->is_private != kvm_mem_is_private(kvm, fault->gfn))" and marking MMIO as private using kvm_vm_ioctl_set_mem_attributes() does not work as kvm_gmem_get_memory_attributes() fails on dmabuf fds.
>
> I worked around this like below but wonder what is the proper way? Thanks,
>
>
> @@ -768,13 +768,13 @@ unsigned long kvm_gmem_get_memory_attributes(struct kvm *kvm, gfn_t gfn)
>   	 */
>   	if (!slot)
>   		return 0;
>
>   	CLASS(gmem_get_file, file)(slot);
>   	if (!file)
> -		return false;
> +		return kvm_get_vm_memory_attributes(kvm, gfn);
>
>   	/*
>   	 * Don't take the filemap invalidation lock, as temporarily acquiring
>   	 * that lock wouldn't provide any meaningful protection.  The caller
>   	 * _must_ protect consumption of private vs. shared by checking
>   	 * mmu_invalidate_retry_gfn() under mmu_lock.
>
>
>
> --
> Alexey