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] [day] [month] [year] [list]

Message-ID: <aYHGVQTF6RUs7r3g@yilunxu-OptiPlex-7050>
Date: Tue, 3 Feb 2026 17:56:37 +0800
From: Xu Yilun <yilun.xu@...ux.intel.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Jason Gunthorpe <jgg@...pe.ca>, Ackerley Tng <ackerleytng@...gle.com>,
	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,
	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,
	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,
	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

> +1.  For guest_memfd, we initially defined per-VM memory attributes to track
> private vs. shared.  But as Ackerley noted, we are in the process of deprecating
> that support, e.g. by making it incompatible with various guest_memfd features,
> in favor of having each guest_memfd instance track the state of a given page.
> 
> The original guest_memfd design was that it would _only_ hold private pages, and
> so tracking private vs. shared in guest_memfd didn't make any sense.  As we've
> pivoted to in-place conversion, tracking private vs. shared in the guest_memfd
> has basically become mandatory.  We could maaaaaybe make it work with per-VM
> attributes, but it would be insanely complex.
> 
> For a dmabuf fd, the story is the same as guest_memfd.  Unless private vs. shared
> is all or nothing, and can never change, then the only entity that can track that
> info is the owner of the dmabuf.  And even if the private vs. shared attributes
> are constant, tracking it external to KVM makes sense, because then the provider
> can simply hardcode %true/%false.  

For CoCo-VM and Tee-IO, I'm wondering if host or KVM has to maintain
the private/shared attribute for "assigned MMIO". I'm not naming them
"host MMIO" cause unlike RAM host never needs to access them, either in
private manner or shared manner.

Traditionally, host maps these MMIOs only because KVM needs HVA->HPA
mapping to find pfn and setup KVM MMU. Now we have FD based approach so
with dmabuf fd, host no longer needs mapping. Does that give confidence
that KVM only needs to setup MMU for this type of MMIO as private/shared
according to guest's intension (which is fault->is_private)?

We don't need to track private/shared in VFIO MMIO dmabuf, only to keep
them unmappable.

> 
> As for _how_ to do that, no matter where the attributes are stored, we're going
> to have to teach KVM to play nice with a non-guest_memfd provider of private
> memory.
>