From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fra-out-003.esa.eu-central-1.outbound.mail-perimeter.amazon.com (fra-out-003.esa.eu-central-1.outbound.mail-perimeter.amazon.com [3.72.182.33]) (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 1CAB36FBF; Wed, 14 Jan 2026 13:45:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=3.72.182.33 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768398339; cv=none; b=Vs9GlNBbFRHyoPlP+oWnr6QzdGI9JpI5qYG0xtATDIYRY1Shy7r4YS5RYjFbAH3YjARHGVLbxOT0hEUSSAD2LVOiun5S9ofccmgAo5TRhWOBdwv5i0wen1Zikz/IrFWOqe21m14lJZNpuwmUksEwFoJ3kO/+ff09nokEldtwKm0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768398339; c=relaxed/simple; bh=JY4ANZUTEJkUasmLys76ti6ML4pdKaKCmVtSa6jInaM=; h=From:To:CC:Subject:Date:Message-ID:Content-Type:MIME-Version; b=PMyToStY03wbHLId3Gefk6ZQFx5WVcKWvoUXVVBTKOs001ukMjXntrzLy9lo28kQk1bqZgRfcNwphUWD92g4RYQ25RxLAfIvgxg9kw/9lvhCug+XijJoLKms9aGCigsbXwllQjHt65KFWw7GWLpEWOEcplTt4BrmW1Pg71H9yok= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.co.uk; spf=pass smtp.mailfrom=amazon.co.uk; dkim=pass (2048-bit key) header.d=amazon.co.uk header.i=@amazon.co.uk header.b=X/OEhShu; arc=none smtp.client-ip=3.72.182.33 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.co.uk Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=amazon.co.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=amazon.co.uk header.i=@amazon.co.uk header.b="X/OEhShu" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.co.uk; i=@amazon.co.uk; q=dns/txt; s=amazoncorp2; t=1768398336; x=1799934336; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=C5qlMH/wtsmcLk6SljUNTD3DCGuIp1OApZnkGozlYCk=; b=X/OEhShu3uLuSdjTC4WgBS1NxmDaeCoHbtDSss/K2KAZVJLUFQn/jUgV BP2mXr+R7DQSYe5IU1qKDtLFLe3a0bcA9YsAMLsy+A2ZJFwl2SaPZIVzW lTc+sa06+SGM/V6thTpY1+gqqby43Oab+fSSClW3I/aA3NmxC7ci8faGZ SAis3paZA16xYAANd6q3eRZQaaN5qharANmVDP3Ni5Hz2tjzBxKGHBSHS P4NDwhqpYRTVpSv6llDQqIbPc/b9BxnP68lHm8vYexiXZQ60U2pL2PX/t rZhp5lYa87SdccxPlQ6ArED+fB8lD+qIAdCh38b7Gb546dNqFYXpPztz2 A==; X-CSE-ConnectionGUID: cAS/p1IlQ+6brG6UAGBozA== X-CSE-MsgGUID: 6cYb4iAZQq6KhV7Q0e9uwA== X-IronPort-AV: E=Sophos;i="6.21,225,1763424000"; d="scan'208";a="7898964" Received: from ip-10-6-6-97.eu-central-1.compute.internal (HELO smtpout.naws.eu-central-1.prod.farcaster.email.amazon.dev) ([10.6.6.97]) by internal-fra-out-003.esa.eu-central-1.outbound.mail-perimeter.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jan 2026 13:45:13 +0000 Received: from EX19MTAEUB002.ant.amazon.com [54.240.197.224:25244] by smtpin.naws.eu-central-1.prod.farcaster.email.amazon.dev [10.0.2.33:2525] with esmtp (Farcaster) id 4d53a730-c517-4321-8200-fcfe21696f25; Wed, 14 Jan 2026 13:45:13 +0000 (UTC) X-Farcaster-Flow-ID: 4d53a730-c517-4321-8200-fcfe21696f25 Received: from EX19D005EUB004.ant.amazon.com (10.252.51.126) by EX19MTAEUB002.ant.amazon.com (10.252.51.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.35; Wed, 14 Jan 2026 13:45:12 +0000 Received: from EX19D005EUB003.ant.amazon.com (10.252.51.31) by EX19D005EUB004.ant.amazon.com (10.252.51.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.35; Wed, 14 Jan 2026 13:45:12 +0000 Received: from EX19D005EUB003.ant.amazon.com ([fe80::b825:becb:4b38:da0c]) by EX19D005EUB003.ant.amazon.com ([fe80::b825:becb:4b38:da0c%3]) with mapi id 15.02.2562.035; Wed, 14 Jan 2026 13:45:12 +0000 From: "Kalyazin, Nikita" To: "kvm@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "kvmarm@lists.linux.dev" , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" , "bpf@vger.kernel.org" , "linux-kselftest@vger.kernel.org" , "kernel@xen0n.name" , "linux-riscv@lists.infradead.org" , "linux-s390@vger.kernel.org" , "loongarch@lists.linux.dev" CC: "pbonzini@redhat.com" , "corbet@lwn.net" , "maz@kernel.org" , "oupton@kernel.org" , "joey.gouly@arm.com" , "suzuki.poulose@arm.com" , "yuzenghui@huawei.com" , "catalin.marinas@arm.com" , "will@kernel.org" , "seanjc@google.com" , "tglx@linutronix.de" , "mingo@redhat.com" , "bp@alien8.de" , "dave.hansen@linux.intel.com" , "x86@kernel.org" , "hpa@zytor.com" , "luto@kernel.org" , "peterz@infradead.org" , "willy@infradead.org" , "akpm@linux-foundation.org" , "david@kernel.org" , "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" , "shuah@kernel.org" , "riel@surriel.com" , "ryan.roberts@arm.com" , "jgross@suse.com" , "yu-cheng.yu@intel.com" , "kas@kernel.org" , "coxu@redhat.com" , "kevin.brodsky@arm.com" , "ackerleytng@google.com" , "maobibo@loongson.cn" , "prsampat@amd.com" , "mlevitsk@redhat.com" , "jmattson@google.com" , "jthoughton@google.com" , "agordeev@linux.ibm.com" , "alex@ghiti.fr" , "aou@eecs.berkeley.edu" , "borntraeger@linux.ibm.com" , "chenhuacai@kernel.org" , "dev.jain@arm.com" , "gor@linux.ibm.com" , "hca@linux.ibm.com" , "Jonathan.Cameron@huawei.com" , "palmer@dabbelt.com" , "pjw@kernel.org" , "shijie@os.amperecomputing.com" , "svens@linux.ibm.com" , "thuth@redhat.com" , "wyihan@google.com" , "yang@os.amperecomputing.com" , "vannapurve@google.com" , "jackmanb@google.com" , "aneesh.kumar@kernel.org" , "patrick.roy@linux.dev" , "Thomson, Jack" , "Itazuri, Takahiro" , "Manwaring, Derek" , "Cali, Marco" , "Kalyazin, Nikita" Subject: [PATCH v9 00/13] Direct Map Removal Support for guest_memfd Thread-Topic: [PATCH v9 00/13] Direct Map Removal Support for guest_memfd Thread-Index: AQHchVwBJodCfIOOzk6JfArIPtu1ug== Date: Wed, 14 Jan 2026 13:45:12 +0000 Message-ID: <20260114134510.1835-1-kalyazin@amazon.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 [ based on kvm/next ]=0A= =0A= Unmapping virtual machine guest memory from the host kernel's direct map=0A= is a successful mitigation against Spectre-style transient execution=0A= issues: if the kernel page tables do not contain entries pointing to=0A= guest memory, then any attempted speculative read through the direct map=0A= will necessarily be blocked by the MMU before any observable=0A= microarchitectural side-effects happen. This means that Spectre-gadgets=0A= and similar cannot be used to target virtual machine memory. Roughly=0A= 60% of speculative execution issues fall into this category [1, Table=0A= 1].=0A= =0A= This patch series extends guest_memfd with the ability to remove its=0A= memory from the host kernel's direct map, to be able to attain the above=0A= protection for KVM guests running inside guest_memfd.=0A= =0A= Additionally, a Firecracker branch with support for these VMs can be=0A= found on GitHub [2].=0A= =0A= For more details, please refer to the v5 cover letter. No substantial=0A= changes in design have taken place since.=0A= =0A= See also related write() syscall support in guest_memfd [3] where=0A= the interoperation between the two features is described.=0A= =0A= Changes since v8:=0A= - Dave: create new helpers for direct map manipulations=0A= (folio_{zap,restore}_direct_map()) instead of using=0A= set_direct_map_valid_noflush() to abstract TLB flush logic=0A= - Dave: add WARN_ON_ONCE on the error when restoring direct map=0A= - John: separate patch for dropping secretmem optimisation in=0A= gup_fast_folio_allowed()=0A= - Vlastimil: add missing clearing of the flag when restoring direct map=0A= - Reorder patches to keep the kernel compilable in between=0A= =0A= v8: https://lore.kernel.org/kvm/20251205165743.9341-1-kalyazin@amazon.com= =0A= v7: https://lore.kernel.org/kvm/20250924151101.2225820-1-patrick.roy@campus= .lmu.de=0A= v6: https://lore.kernel.org/kvm/20250912091708.17502-1-roypat@amazon.co.uk= =0A= v5: https://lore.kernel.org/kvm/20250828093902.2719-1-roypat@amazon.co.uk= =0A= v4: https://lore.kernel.org/kvm/20250221160728.1584559-1-roypat@amazon.co.u= k=0A= RFCv3: https://lore.kernel.org/kvm/20241030134912.515725-1-roypat@amazon.co= .uk=0A= RFCv2: https://lore.kernel.org/kvm/20240910163038.1298452-1-roypat@amazon.c= o.uk=0A= RFCv1: https://lore.kernel.org/kvm/20240709132041.3625501-1-roypat@amazon.c= o.uk=0A= =0A= [1] https://download.vusec.net/papers/quarantine_raid23.pdf=0A= [2] https://github.com/firecracker-microvm/firecracker/tree/feature/secret-= hiding=0A= [3] https://lore.kernel.org/kvm/20251114151828.98165-1-kalyazin@amazon.com= =0A= =0A= Nikita Kalyazin (1):=0A= set_memory: add folio_{zap,restore}_direct_map helpers=0A= =0A= Patrick Roy (12):=0A= mm/gup: drop secretmem optimization from gup_fast_folio_allowed=0A= mm: introduce AS_NO_DIRECT_MAP=0A= KVM: guest_memfd: Add stub for kvm_arch_gmem_invalidate=0A= KVM: x86: define kvm_arch_gmem_supports_no_direct_map()=0A= KVM: arm64: define kvm_arch_gmem_supports_no_direct_map()=0A= KVM: guest_memfd: Add flag to remove from direct map=0A= KVM: selftests: load elf via bounce buffer=0A= KVM: selftests: set KVM_MEM_GUEST_MEMFD in vm_mem_add() if guest_memfd=0A= !=3D -1=0A= KVM: selftests: Add guest_memfd based vm_mem_backing_src_types=0A= KVM: selftests: cover GUEST_MEMFD_FLAG_NO_DIRECT_MAP in existing=0A= selftests=0A= KVM: selftests: stuff vm_mem_backing_src_type into vm_shape=0A= KVM: selftests: Test guest execution from direct map removed gmem=0A= =0A= Documentation/virt/kvm/api.rst | 22 ++++---=0A= arch/arm64/include/asm/kvm_host.h | 13 ++++=0A= arch/arm64/include/asm/set_memory.h | 2 +=0A= arch/arm64/mm/pageattr.c | 12 ++++=0A= arch/loongarch/include/asm/set_memory.h | 2 +=0A= arch/loongarch/mm/pageattr.c | 16 +++++=0A= arch/riscv/include/asm/set_memory.h | 2 +=0A= arch/riscv/mm/pageattr.c | 16 +++++=0A= arch/s390/include/asm/set_memory.h | 2 +=0A= arch/s390/mm/pageattr.c | 18 ++++++=0A= arch/x86/include/asm/kvm_host.h | 9 +++=0A= arch/x86/include/asm/set_memory.h | 2 +=0A= arch/x86/mm/pat/set_memory.c | 20 +++++++=0A= include/linux/kvm_host.h | 14 +++++=0A= include/linux/pagemap.h | 16 +++++=0A= include/linux/secretmem.h | 18 ------=0A= include/linux/set_memory.h | 10 ++++=0A= include/uapi/linux/kvm.h | 1 +=0A= lib/buildid.c | 4 +-=0A= mm/gup.c | 19 ++----=0A= mm/mlock.c | 2 +-=0A= mm/secretmem.c | 8 +--=0A= .../testing/selftests/kvm/guest_memfd_test.c | 17 +++++-=0A= .../testing/selftests/kvm/include/kvm_util.h | 37 +++++++++---=0A= .../testing/selftests/kvm/include/test_util.h | 8 +++=0A= tools/testing/selftests/kvm/lib/elf.c | 8 +--=0A= tools/testing/selftests/kvm/lib/io.c | 23 ++++++++=0A= tools/testing/selftests/kvm/lib/kvm_util.c | 59 +++++++++++--------=0A= tools/testing/selftests/kvm/lib/test_util.c | 8 +++=0A= tools/testing/selftests/kvm/lib/x86/sev.c | 1 +=0A= .../selftests/kvm/pre_fault_memory_test.c | 1 +=0A= .../selftests/kvm/set_memory_region_test.c | 52 ++++++++++++++--=0A= .../kvm/x86/private_mem_conversions_test.c | 7 ++-=0A= virt/kvm/guest_memfd.c | 58 ++++++++++++++++--=0A= 34 files changed, 406 insertions(+), 101 deletions(-)=0A= =0A= =0A= base-commit: 0499add8efd72456514c6218c062911ccc922a99=0A= -- =0A= 2.50.1=0A= =0A=