| 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
| ||
|
Message-ID: <20260114134510.1835-1-kalyazin@amazon.com>
Date: Wed, 14 Jan 2026 13:45:12 +0000
From: "Kalyazin, Nikita" <kalyazin@...zon.co.uk>
To: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "linux-doc@...r.kernel.org"
<linux-doc@...r.kernel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "kvmarm@...ts.linux.dev"
<kvmarm@...ts.linux.dev>, "linux-fsdevel@...r.kernel.org"
<linux-fsdevel@...r.kernel.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>,
"kernel@...0n.name" <kernel@...0n.name>, "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>
CC: "pbonzini@...hat.com" <pbonzini@...hat.com>, "corbet@....net"
<corbet@....net>, "maz@...nel.org" <maz@...nel.org>, "oupton@...nel.org"
<oupton@...nel.org>, "joey.gouly@....com" <joey.gouly@....com>,
"suzuki.poulose@....com" <suzuki.poulose@....com>, "yuzenghui@...wei.com"
<yuzenghui@...wei.com>, "catalin.marinas@....com" <catalin.marinas@....com>,
"will@...nel.org" <will@...nel.org>, "seanjc@...gle.com" <seanjc@...gle.com>,
"tglx@...utronix.de" <tglx@...utronix.de>, "mingo@...hat.com"
<mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, "x86@...nel.org"
<x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>, "luto@...nel.org"
<luto@...nel.org>, "peterz@...radead.org" <peterz@...radead.org>,
"willy@...radead.org" <willy@...radead.org>, "akpm@...ux-foundation.org"
<akpm@...ux-foundation.org>, "david@...nel.org" <david@...nel.org>,
"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>, "shuah@...nel.org" <shuah@...nel.org>,
"riel@...riel.com" <riel@...riel.com>, "ryan.roberts@....com"
<ryan.roberts@....com>, "jgross@...e.com" <jgross@...e.com>,
"yu-cheng.yu@...el.com" <yu-cheng.yu@...el.com>, "kas@...nel.org"
<kas@...nel.org>, "coxu@...hat.com" <coxu@...hat.com>,
"kevin.brodsky@....com" <kevin.brodsky@....com>, "ackerleytng@...gle.com"
<ackerleytng@...gle.com>, "maobibo@...ngson.cn" <maobibo@...ngson.cn>,
"prsampat@....com" <prsampat@....com>, "mlevitsk@...hat.com"
<mlevitsk@...hat.com>, "jmattson@...gle.com" <jmattson@...gle.com>,
"jthoughton@...gle.com" <jthoughton@...gle.com>, "agordeev@...ux.ibm.com"
<agordeev@...ux.ibm.com>, "alex@...ti.fr" <alex@...ti.fr>,
"aou@...s.berkeley.edu" <aou@...s.berkeley.edu>, "borntraeger@...ux.ibm.com"
<borntraeger@...ux.ibm.com>, "chenhuacai@...nel.org" <chenhuacai@...nel.org>,
"dev.jain@....com" <dev.jain@....com>, "gor@...ux.ibm.com"
<gor@...ux.ibm.com>, "hca@...ux.ibm.com" <hca@...ux.ibm.com>,
"Jonathan.Cameron@...wei.com" <Jonathan.Cameron@...wei.com>,
"palmer@...belt.com" <palmer@...belt.com>, "pjw@...nel.org" <pjw@...nel.org>,
"shijie@...amperecomputing.com" <shijie@...amperecomputing.com>,
"svens@...ux.ibm.com" <svens@...ux.ibm.com>, "thuth@...hat.com"
<thuth@...hat.com>, "wyihan@...gle.com" <wyihan@...gle.com>,
"yang@...amperecomputing.com" <yang@...amperecomputing.com>,
"vannapurve@...gle.com" <vannapurve@...gle.com>, "jackmanb@...gle.com"
<jackmanb@...gle.com>, "aneesh.kumar@...nel.org" <aneesh.kumar@...nel.org>,
"patrick.roy@...ux.dev" <patrick.roy@...ux.dev>, "Thomson, Jack"
<jackabt@...zon.co.uk>, "Itazuri, Takahiro" <itazur@...zon.co.uk>,
"Manwaring, Derek" <derekmn@...zon.com>, "Cali, Marco"
<xmarcalx@...zon.co.uk>, "Kalyazin, Nikita" <kalyazin@...zon.co.uk>
Subject: [PATCH v9 00/13] Direct Map Removal Support for guest_memfd
[ based on kvm/next ]
Unmapping virtual machine guest memory from the host kernel's direct map
is a successful mitigation against Spectre-style transient execution
issues: if the kernel page tables do not contain entries pointing to
guest memory, then any attempted speculative read through the direct map
will necessarily be blocked by the MMU before any observable
microarchitectural side-effects happen. This means that Spectre-gadgets
and similar cannot be used to target virtual machine memory. Roughly
60% of speculative execution issues fall into this category [1, Table
1].
This patch series extends guest_memfd with the ability to remove its
memory from the host kernel's direct map, to be able to attain the above
protection for KVM guests running inside guest_memfd.
Additionally, a Firecracker branch with support for these VMs can be
found on GitHub [2].
For more details, please refer to the v5 cover letter. No substantial
changes in design have taken place since.
See also related write() syscall support in guest_memfd [3] where
the interoperation between the two features is described.
Changes since v8:
- Dave: create new helpers for direct map manipulations
(folio_{zap,restore}_direct_map()) instead of using
set_direct_map_valid_noflush() to abstract TLB flush logic
- Dave: add WARN_ON_ONCE on the error when restoring direct map
- John: separate patch for dropping secretmem optimisation in
gup_fast_folio_allowed()
- Vlastimil: add missing clearing of the flag when restoring direct map
- Reorder patches to keep the kernel compilable in between
v8: https://lore.kernel.org/kvm/20251205165743.9341-1-kalyazin@amazon.com
v7: https://lore.kernel.org/kvm/20250924151101.2225820-1-patrick.roy@campus.lmu.de
v6: https://lore.kernel.org/kvm/20250912091708.17502-1-roypat@amazon.co.uk
v5: https://lore.kernel.org/kvm/20250828093902.2719-1-roypat@amazon.co.uk
v4: https://lore.kernel.org/kvm/20250221160728.1584559-1-roypat@amazon.co.uk
RFCv3: https://lore.kernel.org/kvm/20241030134912.515725-1-roypat@amazon.co.uk
RFCv2: https://lore.kernel.org/kvm/20240910163038.1298452-1-roypat@amazon.co.uk
RFCv1: https://lore.kernel.org/kvm/20240709132041.3625501-1-roypat@amazon.co.uk
[1] https://download.vusec.net/papers/quarantine_raid23.pdf
[2] https://github.com/firecracker-microvm/firecracker/tree/feature/secret-hiding
[3] https://lore.kernel.org/kvm/20251114151828.98165-1-kalyazin@amazon.com
Nikita Kalyazin (1):
set_memory: add folio_{zap,restore}_direct_map helpers
Patrick Roy (12):
mm/gup: drop secretmem optimization from gup_fast_folio_allowed
mm: introduce AS_NO_DIRECT_MAP
KVM: guest_memfd: Add stub for kvm_arch_gmem_invalidate
KVM: x86: define kvm_arch_gmem_supports_no_direct_map()
KVM: arm64: define kvm_arch_gmem_supports_no_direct_map()
KVM: guest_memfd: Add flag to remove from direct map
KVM: selftests: load elf via bounce buffer
KVM: selftests: set KVM_MEM_GUEST_MEMFD in vm_mem_add() if guest_memfd
!= -1
KVM: selftests: Add guest_memfd based vm_mem_backing_src_types
KVM: selftests: cover GUEST_MEMFD_FLAG_NO_DIRECT_MAP in existing
selftests
KVM: selftests: stuff vm_mem_backing_src_type into vm_shape
KVM: selftests: Test guest execution from direct map removed gmem
Documentation/virt/kvm/api.rst | 22 ++++---
arch/arm64/include/asm/kvm_host.h | 13 ++++
arch/arm64/include/asm/set_memory.h | 2 +
arch/arm64/mm/pageattr.c | 12 ++++
arch/loongarch/include/asm/set_memory.h | 2 +
arch/loongarch/mm/pageattr.c | 16 +++++
arch/riscv/include/asm/set_memory.h | 2 +
arch/riscv/mm/pageattr.c | 16 +++++
arch/s390/include/asm/set_memory.h | 2 +
arch/s390/mm/pageattr.c | 18 ++++++
arch/x86/include/asm/kvm_host.h | 9 +++
arch/x86/include/asm/set_memory.h | 2 +
arch/x86/mm/pat/set_memory.c | 20 +++++++
include/linux/kvm_host.h | 14 +++++
include/linux/pagemap.h | 16 +++++
include/linux/secretmem.h | 18 ------
include/linux/set_memory.h | 10 ++++
include/uapi/linux/kvm.h | 1 +
lib/buildid.c | 4 +-
mm/gup.c | 19 ++----
mm/mlock.c | 2 +-
mm/secretmem.c | 8 +--
.../testing/selftests/kvm/guest_memfd_test.c | 17 +++++-
.../testing/selftests/kvm/include/kvm_util.h | 37 +++++++++---
.../testing/selftests/kvm/include/test_util.h | 8 +++
tools/testing/selftests/kvm/lib/elf.c | 8 +--
tools/testing/selftests/kvm/lib/io.c | 23 ++++++++
tools/testing/selftests/kvm/lib/kvm_util.c | 59 +++++++++++--------
tools/testing/selftests/kvm/lib/test_util.c | 8 +++
tools/testing/selftests/kvm/lib/x86/sev.c | 1 +
.../selftests/kvm/pre_fault_memory_test.c | 1 +
.../selftests/kvm/set_memory_region_test.c | 52 ++++++++++++++--
.../kvm/x86/private_mem_conversions_test.c | 7 ++-
virt/kvm/guest_memfd.c | 58 ++++++++++++++++--
34 files changed, 406 insertions(+), 101 deletions(-)
base-commit: 0499add8efd72456514c6218c062911ccc922a99
--
2.50.1
Powered by blists - more mailing lists