From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2BD602D63FF; Thu, 18 Sep 2025 20:21:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758226894; cv=none; b=qKdJnA1YLkQydCErlN8ga6i9euOY9I2htwqyPWTlmCpBnjAc/FB730eNaVGHr8ExNmsVG5p3Fetg8HuGjzqxj2kbjQQXmCf0O9WGNLCcuN9U6YnLiBuOi+us9+ZlmG901uFokqpPMHkLrABkhwZey9ADImRv23RI69PFiaCxshU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758226894; c=relaxed/simple; bh=qP3MQwM1EJ5Gl9Y7CUEowkPmBRxV9f3jSqmnplG0VdM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=nFL/BX/Zg/afwPcSUNk7IKzyJ3IZGcymR3cmqSetMg1m0DiLZwew31dtHmjIExm+CzIIjDgaKW7ZfwfuihO2bWJHsHmOBO+/Qr+lMHpYnLuds0jOBGPLhtF9OKj6m02FGJGxzn0PGm3ZDwZvRh+IHQ6nX3X/9N7xtXbZUnEGbrw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HieRAthe; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HieRAthe" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1F889C4CEFA; Thu, 18 Sep 2025 20:21:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1758226893; bh=qP3MQwM1EJ5Gl9Y7CUEowkPmBRxV9f3jSqmnplG0VdM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=HieRAtheU5vVyO0d5vlDxkmm48RkpTsr//AeI0V2zteg8QCexEI2Jtz0O8TSNFUE9 kUquWWzeDw7+4JIu6biklnBx4qNpB7U9ffrqjdd0TP4OdcxbkyOb4Dqmt6Y/91NB9C A+ux3oIEFvGRN9Vp5TWR//wTmLWE0W0w4A8QFbk1dEWHrrmQOn4joi/a4SlFm2120m PuW6/Y44NqxWjR7/4eDN/f0TVQ1Vqfw3FIF5333VpqgxYlPumDb18T2C+EvlJ3fAr6 f1oroXfTYkRKJMzwPsh34GBorkUDauXKVjBQoKTeoNiY5+6DuSY6yM4r3t+km9GrJK UJar4yMGrmVJA== Date: Thu, 18 Sep 2025 21:21:16 +0100 From: Will Deacon To: "Roy, Patrick" Cc: "Thomson, Jack" , "Kalyazin, Nikita" , "Cali, Marco" , "derekmn@amazon.co.uk" , "willy@infradead.org" , "corbet@lwn.net" , "pbonzini@redhat.com" , "maz@kernel.org" , "oliver.upton@linux.dev" , "joey.gouly@arm.com" , "suzuki.poulose@arm.com" , "yuzenghui@huawei.com" , "catalin.marinas@arm.com" , "chenhuacai@kernel.org" , "kernel@xen0n.name" , "paul.walmsley@sifive.com" , "palmer@dabbelt.com" , "aou@eecs.berkeley.edu" , "alex@ghiti.fr" , "agordeev@linux.ibm.com" , "gerald.schaefer@linux.ibm.com" , "hca@linux.ibm.com" , "gor@linux.ibm.com" , "borntraeger@linux.ibm.com" , "svens@linux.ibm.com" , "dave.hansen@linux.intel.com" , "luto@kernel.org" , "peterz@infradead.org" , "tglx@linutronix.de" , "mingo@redhat.com" , "bp@alien8.de" , "x86@kernel.org" , "hpa@zytor.com" , "trondmy@kernel.org" , "anna@kernel.org" , "hubcap@omnibond.com" , "martin@omnibond.com" , "viro@zeniv.linux.org.uk" , "brauner@kernel.org" , "jack@suse.cz" , "akpm@linux-foundation.org" , "david@redhat.com" , "lorenzo.stoakes@oracle.com" , "Liam.Howlett@oracle.com" , "vbabka@suse.cz" , "rppt@kernel.org" , "surenb@google.com" , "mhocko@suse.com" , "ast@kernel.org" , "daniel@iogearbox.net" , "andrii@kernel.org" , "martin.lau@linux.dev" , "eddyz87@gmail.com" , "song@kernel.org" , "yonghong.song@linux.dev" , "john.fastabend@gmail.com" , "kpsingh@kernel.org" , "sdf@fomichev.me" , "haoluo@google.com" , "jolsa@kernel.org" , "jgg@ziepe.ca" , "jhubbard@nvidia.com" , "peterx@redhat.com" , "jannh@google.com" , "pfalcato@suse.de" , "axelrasmussen@google.com" , "yuanchu@google.com" , "weixugc@google.com" , "hannes@cmpxchg.org" , "zhengqi.arch@bytedance.com" , "shakeel.butt@linux.dev" , "shuah@kernel.org" , "seanjc@google.com" , "linux-fsdevel@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "kvmarm@lists.linux.dev" , "loongarch@lists.linux.dev" , "linux-riscv@lists.infradead.org" , "linux-s390@vger.kernel.org" , "linux-nfs@vger.kernel.org" , "devel@lists.orangefs.org" , "linux-mm@kvack.org" , "bpf@vger.kernel.org" , "linux-kselftest@vger.kernel.org" Subject: Re: [PATCH v6 05/11] KVM: guest_memfd: Add flag to remove from direct map Message-ID: References: <20250912091708.17502-1-roypat@amazon.co.uk> <20250912091708.17502-6-roypat@amazon.co.uk> Precedence: bulk X-Mailing-List: linux-kselftest@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250912091708.17502-6-roypat@amazon.co.uk> 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