Message-ID: <aMxpvI6Aj8mDsRNm@willie-the-truck>
Date: Thu, 18 Sep 2025 21:21:16 +0100
From: Will Deacon <will@...nel.org>
To: "Roy, Patrick" <roypat@...zon.co.uk>
Cc: "Thomson, Jack" <jackabt@...zon.co.uk>,
	"Kalyazin, Nikita" <kalyazin@...zon.co.uk>,
	"Cali, Marco" <xmarcalx@...zon.co.uk>,
	"derekmn@...zon.co.uk" <derekmn@...zon.co.uk>,
	"willy@...radead.org" <willy@...radead.org>,
	"corbet@....net" <corbet@....net>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>,
	"maz@...nel.org" <maz@...nel.org>,
	"oliver.upton@...ux.dev" <oliver.upton@...ux.dev>,
	"joey.gouly@....com" <joey.gouly@....com>,
	"suzuki.poulose@....com" <suzuki.poulose@....com>,
	"yuzenghui@...wei.com" <yuzenghui@...wei.com>,
	"catalin.marinas@....com" <catalin.marinas@....com>,
	"chenhuacai@...nel.org" <chenhuacai@...nel.org>,
	"kernel@...0n.name" <kernel@...0n.name>,
	"paul.walmsley@...ive.com" <paul.walmsley@...ive.com>,
	"palmer@...belt.com" <palmer@...belt.com>,
	"aou@...s.berkeley.edu" <aou@...s.berkeley.edu>,
	"alex@...ti.fr" <alex@...ti.fr>,
	"agordeev@...ux.ibm.com" <agordeev@...ux.ibm.com>,
	"gerald.schaefer@...ux.ibm.com" <gerald.schaefer@...ux.ibm.com>,
	"hca@...ux.ibm.com" <hca@...ux.ibm.com>,
	"gor@...ux.ibm.com" <gor@...ux.ibm.com>,
	"borntraeger@...ux.ibm.com" <borntraeger@...ux.ibm.com>,
	"svens@...ux.ibm.com" <svens@...ux.ibm.com>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
	"luto@...nel.org" <luto@...nel.org>,
	"peterz@...radead.org" <peterz@...radead.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"bp@...en8.de" <bp@...en8.de>, "x86@...nel.org" <x86@...nel.org>,
	"hpa@...or.com" <hpa@...or.com>,
	"trondmy@...nel.org" <trondmy@...nel.org>,
	"anna@...nel.org" <anna@...nel.org>,
	"hubcap@...ibond.com" <hubcap@...ibond.com>,
	"martin@...ibond.com" <martin@...ibond.com>,
	"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
	"brauner@...nel.org" <brauner@...nel.org>,
	"jack@...e.cz" <jack@...e.cz>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"david@...hat.com" <david@...hat.com>,
	"lorenzo.stoakes@...cle.com" <lorenzo.stoakes@...cle.com>,
	"Liam.Howlett@...cle.com" <Liam.Howlett@...cle.com>,
	"vbabka@...e.cz" <vbabka@...e.cz>,
	"rppt@...nel.org" <rppt@...nel.org>,
	"surenb@...gle.com" <surenb@...gle.com>,
	"mhocko@...e.com" <mhocko@...e.com>,
	"ast@...nel.org" <ast@...nel.org>,
	"daniel@...earbox.net" <daniel@...earbox.net>,
	"andrii@...nel.org" <andrii@...nel.org>,
	"martin.lau@...ux.dev" <martin.lau@...ux.dev>,
	"eddyz87@...il.com" <eddyz87@...il.com>,
	"song@...nel.org" <song@...nel.org>,
	"yonghong.song@...ux.dev" <yonghong.song@...ux.dev>,
	"john.fastabend@...il.com" <john.fastabend@...il.com>,
	"kpsingh@...nel.org" <kpsingh@...nel.org>,
	"sdf@...ichev.me" <sdf@...ichev.me>,
	"haoluo@...gle.com" <haoluo@...gle.com>,
	"jolsa@...nel.org" <jolsa@...nel.org>,
	"jgg@...pe.ca" <jgg@...pe.ca>,
	"jhubbard@...dia.com" <jhubbard@...dia.com>,
	"peterx@...hat.com" <peterx@...hat.com>,
	"jannh@...gle.com" <jannh@...gle.com>,
	"pfalcato@...e.de" <pfalcato@...e.de>,
	"axelrasmussen@...gle.com" <axelrasmussen@...gle.com>,
	"yuanchu@...gle.com" <yuanchu@...gle.com>,
	"weixugc@...gle.com" <weixugc@...gle.com>,
	"hannes@...xchg.org" <hannes@...xchg.org>,
	"zhengqi.arch@...edance.com" <zhengqi.arch@...edance.com>,
	"shakeel.butt@...ux.dev" <shakeel.butt@...ux.dev>,
	"shuah@...nel.org" <shuah@...nel.org>,
	"seanjc@...gle.com" <seanjc@...gle.com>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>,
	"loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>,
	"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
	"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
	"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
	"devel@...ts.orangefs.org" <devel@...ts.orangefs.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"bpf@...r.kernel.org" <bpf@...r.kernel.org>,
	"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>
Subject: Re: [PATCH v6 05/11] KVM: guest_memfd: Add flag to remove from
 direct map

Hi Patrick,

We chatted briefly at KVM Forum, so I wanted to chime in here too from
the arm64 side.

On Fri, Sep 12, 2025 at 09:17:37AM +0000, Roy, Patrick wrote:
> Add GUEST_MEMFD_FLAG_NO_DIRECT_MAP flag for KVM_CREATE_GUEST_MEMFD()
> ioctl. When set, guest_memfd folios will be removed from the direct map
> after preparation, with direct map entries only restored when the folios
> are freed.
> 
> To ensure these folios do not end up in places where the kernel cannot
> deal with them, set AS_NO_DIRECT_MAP on the guest_memfd's struct
> address_space if GUEST_MEMFD_FLAG_NO_DIRECT_MAP is requested.
> 
> Add KVM_CAP_GUEST_MEMFD_NO_DIRECT_MAP to let userspace discover whether
> guest_memfd supports GUEST_MEMFD_FLAG_NO_DIRECT_MAP. Support depends on
> guest_memfd itself being supported, but also on whether linux supports
> manipulatomg the direct map at page granularity at all (possible most of
> the time, outliers being arm64 where its impossible if the direct map
> has been setup using hugepages, as arm64 cannot break these apart due to
> break-before-make semantics, and powerpc, which does not select
> ARCH_HAS_SET_DIRECT_MAP, which also doesn't support guest_memfd anyway
> though).
> 
> Note that this flag causes removal of direct map entries for all
> guest_memfd folios independent of whether they are "shared" or "private"
> (although current guest_memfd only supports either all folios in the
> "shared" state, or all folios in the "private" state if
> GUEST_MEMFD_FLAG_MMAP is not set). The usecase for removing direct map
> entries of also the shared parts of guest_memfd are a special type of
> non-CoCo VM where, host userspace is trusted to have access to all of
> guest memory, but where Spectre-style transient execution attacks
> through the host kernel's direct map should still be mitigated.  In this
> setup, KVM retains access to guest memory via userspace mappings of
> guest_memfd, which are reflected back into KVM's memslots via
> userspace_addr. This is needed for things like MMIO emulation on x86_64
> to work.
> 
> Do not perform TLB flushes after direct map manipulations. This is
> because TLB flushes resulted in a up to 40x elongation of page faults in
> guest_memfd (scaling with the number of CPU cores), or a 5x elongation
> of memory population. TLB flushes are not needed for functional
> correctness (the virt->phys mapping technically stays "correct",  the
> kernel should simply not use it for a while). On the other hand, it means
> that the desired protection from Spectre-style attacks is not perfect,
> as an attacker could try to prevent a stale TLB entry from getting
> evicted, keeping it alive until the page it refers to is used by the
> guest for some sensitive data, and then targeting it using a
> spectre-gadget.

I'm really not keen on this last part (at least, for arm64).

If you're not going to bother invalidating the TLB after unmapping from
the direct map because of performance reasons, you're better off just
leaving the direct map intact and getting even better performance. On
arm64, that would mean you could use block mappings too.

On the other hand, if you actually care about the security properties
from the unmap then you need the invalidation so that the mapping
doesn't linger around. With "modern" CPU features such as pte
aggregation and shared TLB walk caches it's not unlikely that these
entries will persist a lot longer than you think and it makes the
security benefits of this series impossible to reason about.

As a compromise, could we make the TLB invalidation an architecture
opt-in so that we can have it enabled on arm64, please?

Will

Powered by blists - more mailing lists