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

Hi Will,

On Thu, 2025-09-18 at 21:21 +0100, Will Deacon wrote:
> 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.

Not until we have hardware with the newest BBM goodies I thought. When I
checked earlier this year, a defconfig has the direct map setup at 4k
granularity.

> 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.

I agree it's not 100% protection, but it is still better than the status quo. I
would also love to have the TLB flushes, but sadly the performance impact of
them would make this completely unusable for Amazon :/

Mh, thinking about it now though, iirc the performance problems were mostly
because all CPUs needed to acknowledge the flush before the issuing CPU could
continue. Is there a way to have "fire and forget" flushes, where we don't wait
for acknowledgements?

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

How about instead of an architecture opt-in, we have some sort of opt-out flag
userspace can set? Similar to the PFNMAP stuff KVM already has.

> Will

Best,
Patrick

Powered by blists - more mailing lists