* [PATCH v2 01/28] KVM: selftests: Take into account mixed memory fault flags
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:15 ` [PATCH v2 02/28] KVM: Define and communicate KVM_EXIT_MEMORY_FAULT RWX flags to userspace Paolo Bonzini
` (26 subsequent siblings)
27 siblings, 0 replies; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
From: Nicolas Saenz Julienne <nsaenz@amazon.com>
Update x86_64/private_mem_kvm_exits_test to take into account memory
fault flags might contain multiple bits set while remaining valid---for
example KVM might return KVM_MEMORY_EXIT_FLAG_READ in addition to
KVM_MEMORY_EXIT_FLAG_PRIVATE.
Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
.../testing/selftests/kvm/x86/private_mem_kvm_exits_test.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/kvm/x86/private_mem_kvm_exits_test.c b/tools/testing/selftests/kvm/x86/private_mem_kvm_exits_test.c
index e6d16e9d6120..33fd73465432 100644
--- a/tools/testing/selftests/kvm/x86/private_mem_kvm_exits_test.c
+++ b/tools/testing/selftests/kvm/x86/private_mem_kvm_exits_test.c
@@ -74,7 +74,8 @@ static void test_private_access_memslot_deleted(void)
exit_reason = (u32)(u64)thread_return;
TEST_ASSERT_EQ(exit_reason, KVM_EXIT_MEMORY_FAULT);
- TEST_ASSERT_EQ(vcpu->run->memory_fault.flags, KVM_MEMORY_EXIT_FLAG_PRIVATE);
+ TEST_ASSERT(vcpu->run->memory_fault.flags & KVM_MEMORY_EXIT_FLAG_PRIVATE,
+ "Memory fault didn't occur on a private memory access");
TEST_ASSERT_EQ(vcpu->run->memory_fault.gpa, EXITS_TEST_GPA);
TEST_ASSERT_EQ(vcpu->run->memory_fault.size, EXITS_TEST_SIZE);
@@ -103,7 +104,8 @@ static void test_private_access_memslot_not_private(void)
exit_reason = run_vcpu_get_exit_reason(vcpu);
TEST_ASSERT_EQ(exit_reason, KVM_EXIT_MEMORY_FAULT);
- TEST_ASSERT_EQ(vcpu->run->memory_fault.flags, KVM_MEMORY_EXIT_FLAG_PRIVATE);
+ TEST_ASSERT(vcpu->run->memory_fault.flags & KVM_MEMORY_EXIT_FLAG_PRIVATE,
+ "Memory fault didn't occur on a private memory access");
TEST_ASSERT_EQ(vcpu->run->memory_fault.gpa, EXITS_TEST_GPA);
TEST_ASSERT_EQ(vcpu->run->memory_fault.size, EXITS_TEST_SIZE);
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v2 02/28] KVM: Define and communicate KVM_EXIT_MEMORY_FAULT RWX flags to userspace
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
2026-09-18 8:15 ` [PATCH v2 01/28] KVM: selftests: Take into account mixed memory fault flags Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:27 ` sashiko-bot
2026-09-18 8:15 ` [PATCH v2 03/28] KVM: selftests: Test address translation for Hyper-V direct L2 hypercalls Paolo Bonzini
` (25 subsequent siblings)
27 siblings, 1 reply; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: nsaenz, vkuznets, snambakam, Anish Moorthy, Sean Christopherson
From: Anish Moorthy <amoorthy@google.com>
kvm_prepare_memory_fault_exit() already takes parameters describing the
RWX-ness of the relevant access but doesn't actually do anything with
them. Define and use the flags necessary to pass this information on to
userspace.
Suggested-by: Sean Christopherson <seanjc@google.com>
Link: https://lore.kernel.org/kvm/ZR4N8cwzTMDanPUY@google.com/
Signed-off-by: Anish Moorthy <amoorthy@google.com>
Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
Documentation/virt/kvm/api.rst | 5 +++++
include/linux/kvm_host.h | 9 ++++++++-
include/uapi/linux/kvm.h | 3 +++
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 4eb7e75a7473..37028ce019e3 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -7279,6 +7279,9 @@ spec refer, https://github.com/riscv/riscv-sbi-doc.
/* KVM_EXIT_MEMORY_FAULT */
struct {
+ #define KVM_MEMORY_EXIT_FLAG_READ (1ULL << 0)
+ #define KVM_MEMORY_EXIT_FLAG_WRITE (1ULL << 1)
+ #define KVM_MEMORY_EXIT_FLAG_EXEC (1ULL << 2)
#define KVM_MEMORY_EXIT_FLAG_PRIVATE (1ULL << 3)
__u64 flags;
__u64 gpa;
@@ -7290,6 +7293,8 @@ could not be resolved by KVM. The 'gpa' and 'size' (in bytes) describe the
guest physical address range [gpa, gpa + size) of the fault. The 'flags' field
describes properties of the faulting access that are likely pertinent:
+ - KVM_MEMORY_EXIT_FLAG_READ/WRITE/EXEC - When set, indicates that the memory
+ fault occurred on a read/write/exec access respectively.
- KVM_MEMORY_EXIT_FLAG_PRIVATE - When set, indicates the memory fault occurred
on a private memory access. When clear, indicates the fault occurred on a
shared access.
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 03bfc92864b6..ce5757e85ae3 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -2546,8 +2546,15 @@ static inline void kvm_prepare_memory_fault_exit(struct kvm_vcpu *vcpu,
vcpu->run->memory_fault.gpa = gpa;
vcpu->run->memory_fault.size = size;
- /* RWX flags are not (yet) defined or communicated to userspace. */
vcpu->run->memory_fault.flags = 0;
+
+ if (is_write)
+ vcpu->run->memory_fault.flags |= KVM_MEMORY_EXIT_FLAG_WRITE;
+ else if (is_exec)
+ vcpu->run->memory_fault.flags |= KVM_MEMORY_EXIT_FLAG_EXEC;
+ else
+ vcpu->run->memory_fault.flags |= KVM_MEMORY_EXIT_FLAG_READ;
+
if (is_private)
vcpu->run->memory_fault.flags |= KVM_MEMORY_EXIT_FLAG_PRIVATE;
}
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index ac2d77d14963..15a3090f067e 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -457,6 +457,9 @@ struct kvm_run {
} notify;
/* KVM_EXIT_MEMORY_FAULT */
struct {
+#define KVM_MEMORY_EXIT_FLAG_READ (1ULL << 0)
+#define KVM_MEMORY_EXIT_FLAG_WRITE (1ULL << 1)
+#define KVM_MEMORY_EXIT_FLAG_EXEC (1ULL << 2)
#define KVM_MEMORY_EXIT_FLAG_PRIVATE (1ULL << 3)
__u64 flags;
__u64 gpa;
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* Re: [PATCH v2 02/28] KVM: Define and communicate KVM_EXIT_MEMORY_FAULT RWX flags to userspace
2026-09-18 8:15 ` [PATCH v2 02/28] KVM: Define and communicate KVM_EXIT_MEMORY_FAULT RWX flags to userspace Paolo Bonzini
@ 2026-09-18 8:27 ` sashiko-bot
0 siblings, 0 replies; 44+ messages in thread
From: sashiko-bot @ 2026-09-18 8:27 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: kvm
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] kvm: missing mirror sync in tools/include/uapi/linux/kvm.h for memory exit flags
--
commit bde51f2cf0c01c45785fd4f593b721d8c5b218c8
Author: Anish Moorthy <amoorthy@google.com>
KVM: Define and communicate KVM_EXIT_MEMORY_FAULT RWX flags to userspace
This commit adds new read, write, and execute flags to the
KVM_EXIT_MEMORY_FAULT UAPI structure to communicate the faulting access
type to userspace.
Link: https://lore.kernel.org/kvm/ZR4N8cwzTMDanPUY@google.com/
[ ... ]
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index ac2d77d149635..15a3090f067e5 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -457,6 +457,9 @@ struct kvm_run {
> } notify;
> /* KVM_EXIT_MEMORY_FAULT */
> struct {
> +#define KVM_MEMORY_EXIT_FLAG_READ (1ULL << 0)
> +#define KVM_MEMORY_EXIT_FLAG_WRITE (1ULL << 1)
> +#define KVM_MEMORY_EXIT_FLAG_EXEC (1ULL << 2)
> #define KVM_MEMORY_EXIT_FLAG_PRIVATE (1ULL << 3)
[Severity: Low]
Does this patch also need to sync the mirrored UAPI header in
tools/include/uapi/linux/kvm.h?
The new KVM_MEMORY_EXIT_FLAG_READ, KVM_MEMORY_EXIT_FLAG_WRITE, and
KVM_MEMORY_EXIT_FLAG_EXEC macros are missing from the tools directory
copy of the UAPI header. This will leave tools building against the
mirrored header without the required definitions.
> __u64 flags;
> __u64 gpa;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918081543.139871-1-pbonzini@redhat.com?part=2
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v2 03/28] KVM: selftests: Test address translation for Hyper-V direct L2 hypercalls
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
2026-09-18 8:15 ` [PATCH v2 01/28] KVM: selftests: Take into account mixed memory fault flags Paolo Bonzini
2026-09-18 8:15 ` [PATCH v2 02/28] KVM: Define and communicate KVM_EXIT_MEMORY_FAULT RWX flags to userspace Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:30 ` sashiko-bot
2026-09-18 8:15 ` [PATCH v2 04/28] KVM: apply nGPA->GPA translation to KVM_HC_CLOCK_PAIRING Paolo Bonzini
` (24 subsequent siblings)
27 siblings, 1 reply; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
Test that the TLB flush hypercalls, when executed by L2, translate their
input addresses through the guest's EPT or NPT.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
tools/testing/selftests/kvm/x86/hyperv_evmcs.c | 13 ++++++++++++-
tools/testing/selftests/kvm/x86/hyperv_svm_test.c | 13 ++++++++++++-
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/kvm/x86/hyperv_evmcs.c b/tools/testing/selftests/kvm/x86/hyperv_evmcs.c
index 63ea1533e4ea..fa80bc78aef7 100644
--- a/tools/testing/selftests/kvm/x86/hyperv_evmcs.c
+++ b/tools/testing/selftests/kvm/x86/hyperv_evmcs.c
@@ -18,6 +18,8 @@
#include "hyperv.h"
#include "vmx.h"
+#define L2_HCALL_INPUT_GPA 0x100000000ull
+
static int ud_count;
static void guest_ud_handler(struct ex_regs *regs)
@@ -60,6 +62,8 @@ void l2_guest_code(void)
rdmsr_from_l2(MSR_GS_BASE); /* intercepted */
/* L2 TLB flush tests */
+ hyperv_hypercall(HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE,
+ L2_HCALL_INPUT_GPA, 0);
hyperv_hypercall(HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE | HV_HYPERCALL_FAST_BIT, 0x0,
HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES | HV_FLUSH_ALL_PROCESSORS);
rdmsr_from_l2(MSR_FS_BASE);
@@ -212,6 +216,7 @@ static struct kvm_vcpu *save_restore_vm(struct kvm_vm *vm,
/* Restore state in a new VM. */
vcpu = vm_recreate_with_one_vcpu(vm);
+ vm_enable_ept(vm);
vcpu_set_hv_cpuid(vcpu);
vcpu_enable_evmcs(vcpu);
vcpu_load_state(vcpu, state);
@@ -228,7 +233,7 @@ static struct kvm_vcpu *save_restore_vm(struct kvm_vm *vm,
int main(int argc, char *argv[])
{
gva_t vmx_pages_gva = 0, hv_pages_gva = 0;
- gva_t hcall_page;
+ gva_t hcall_input_page, hcall_page;
struct kvm_vcpu *vcpu;
struct kvm_vm *vm;
@@ -239,17 +244,23 @@ int main(int argc, char *argv[])
TEST_REQUIRE(kvm_has_cap(KVM_CAP_NESTED_STATE));
TEST_REQUIRE(kvm_has_cap(KVM_CAP_HYPERV_ENLIGHTENED_VMCS));
TEST_REQUIRE(kvm_hv_cpu_has(HV_X64_NESTED_DIRECT_FLUSH));
+ TEST_REQUIRE(kvm_cpu_has_ept());
vm = vm_create_with_one_vcpu(&vcpu, guest_code);
+ vm_enable_ept(vm);
hcall_page = vm_alloc_pages(vm, 1);
memset(addr_gva2hva(vm, hcall_page), 0x0, getpagesize());
+ hcall_input_page = vm_alloc_page(vm);
+ memset(addr_gva2hva(vm, hcall_input_page), 0, getpagesize());
vcpu_set_hv_cpuid(vcpu);
vcpu_enable_evmcs(vcpu);
vcpu_alloc_vmx(vm, &vmx_pages_gva);
vcpu_alloc_hyperv_test_pages(vm, &hv_pages_gva);
+ tdp_identity_map_default_memslots(vm);
+ tdp_map(vm, L2_HCALL_INPUT_GPA, addr_gva2gpa(vm, hcall_input_page), PAGE_SIZE);
vcpu_args_set(vcpu, 3, vmx_pages_gva, hv_pages_gva, addr_gva2gpa(vm, hcall_page));
vcpu_set_msr(vcpu, HV_X64_MSR_VP_INDEX, vcpu->id);
diff --git a/tools/testing/selftests/kvm/x86/hyperv_svm_test.c b/tools/testing/selftests/kvm/x86/hyperv_svm_test.c
index 1f74b0fa9b83..18f0ad6debd8 100644
--- a/tools/testing/selftests/kvm/x86/hyperv_svm_test.c
+++ b/tools/testing/selftests/kvm/x86/hyperv_svm_test.c
@@ -18,6 +18,8 @@
#include "svm_util.h"
#include "hyperv.h"
+#define L2_HCALL_INPUT_GPA 0x100000000ull
+
/* Exit to L1 from L2 with RDMSR instruction */
static inline void rdmsr_from_l2(u32 msr)
{
@@ -45,6 +47,8 @@ void l2_guest_code(void)
GUEST_SYNC(5);
/* L2 TLB flush tests */
+ hyperv_hypercall(HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE,
+ L2_HCALL_INPUT_GPA, 0);
hyperv_hypercall(HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE |
HV_HYPERCALL_FAST_BIT, 0x0,
HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES |
@@ -146,7 +150,7 @@ static void __attribute__((__flatten__)) guest_code(struct svm_test_data *svm,
int main(int argc, char *argv[])
{
gva_t nested_gva = 0, hv_pages_gva = 0;
- gva_t hcall_page;
+ gva_t hcall_input_page, hcall_page;
struct kvm_vcpu *vcpu;
struct kvm_vm *vm;
struct ucall uc;
@@ -154,15 +158,22 @@ int main(int argc, char *argv[])
TEST_REQUIRE(kvm_cpu_has(X86_FEATURE_SVM));
TEST_REQUIRE(kvm_hv_cpu_has(HV_X64_NESTED_DIRECT_FLUSH));
+ TEST_REQUIRE(kvm_cpu_has_npt());
/* Create VM */
vm = vm_create_with_one_vcpu(&vcpu, guest_code);
+ vm_enable_npt(vm);
vcpu_set_hv_cpuid(vcpu);
vcpu_alloc_svm(vm, &nested_gva);
vcpu_alloc_hyperv_test_pages(vm, &hv_pages_gva);
hcall_page = vm_alloc_pages(vm, 1);
memset(addr_gva2hva(vm, hcall_page), 0x0, getpagesize());
+ hcall_input_page = vm_alloc_page(vm);
+ memset(addr_gva2hva(vm, hcall_input_page), 0, getpagesize());
+
+ tdp_identity_map_default_memslots(vm);
+ tdp_map(vm, L2_HCALL_INPUT_GPA, addr_gva2gpa(vm, hcall_input_page), PAGE_SIZE);
vcpu_args_set(vcpu, 3, nested_gva, hv_pages_gva, addr_gva2gpa(vm, hcall_page));
vcpu_set_msr(vcpu, HV_X64_MSR_VP_INDEX, vcpu->id);
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* Re: [PATCH v2 03/28] KVM: selftests: Test address translation for Hyper-V direct L2 hypercalls
2026-09-18 8:15 ` [PATCH v2 03/28] KVM: selftests: Test address translation for Hyper-V direct L2 hypercalls Paolo Bonzini
@ 2026-09-18 8:30 ` sashiko-bot
0 siblings, 0 replies; 44+ messages in thread
From: sashiko-bot @ 2026-09-18 8:30 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: kvm
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] selftests/kvm: assertion failure in hyperv_evmcs test due to redundant vm_enable_ept()
--
commit 3101456ba54ccd614ac31b337348b4588da927e6
Author: Paolo Bonzini <pbonzini@redhat.com>
KVM: selftests: Test address translation for Hyper-V direct L2 hypercalls
Test that the TLB flush hypercalls, when executed by L2, translate their
input addresses through the guest's EPT or NPT.
> diff --git a/tools/testing/selftests/kvm/x86/hyperv_evmcs.c b/tools/testing/selftests/kvm/x86/hyperv_evmcs.c
> index 63ea1533e4ead..fa80bc78aef70 100644
> --- a/tools/testing/selftests/kvm/x86/hyperv_evmcs.c
> +++ b/tools/testing/selftests/kvm/x86/hyperv_evmcs.c
[ ... ]
> @@ -212,6 +216,7 @@ static struct kvm_vcpu *save_restore_vm(struct kvm_vm *vm,
>
> /* Restore state in a new VM. */
> vcpu = vm_recreate_with_one_vcpu(vm);
> + vm_enable_ept(vm);
[Severity: Medium]
Does this redundant vm_enable_ept() call cause an assertion failure?
The hyperv_evmcs test periodically simulates live migration by calling
save_restore_vm(). This function calls vm_recreate_with_one_vcpu(), which
recreates the vCPU but preserves the existing kvm_vm object and its
initialized stage2_mmu configuration.
Calling vm_enable_ept(vm) here delegates to tdp_mmu_init(). Since
tdp_mmu_init() expects to run only once per VM, it checks:
TEST_ASSERT(!vm->stage2_mmu.pgtable_levels, "TDP MMU already initialized");
Because pgtable_levels was already set to 4 during the initial
vm_enable_ept(vm) call in main(), this assertion fails, crashing the test
unconditionally on the very first live migration cycle.
> vcpu_set_hv_cpuid(vcpu);
> vcpu_enable_evmcs(vcpu);
> vcpu_load_state(vcpu, state);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918081543.139871-1-pbonzini@redhat.com?part=3
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v2 04/28] KVM: apply nGPA->GPA translation to KVM_HC_CLOCK_PAIRING
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
` (2 preceding siblings ...)
2026-09-18 8:15 ` [PATCH v2 03/28] KVM: selftests: Test address translation for Hyper-V direct L2 hypercalls Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:34 ` sashiko-bot
2026-09-18 8:15 ` [PATCH v2 05/28] KVM: x86: Introduce memory fault on invalid hypercalls reads/writes Paolo Bonzini
` (23 subsequent siblings)
27 siblings, 1 reply; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
KVM_HC_CLOCK_PAIRING writes to a guest physical addresses. Treat it
as an L2 address when running nested, which is consistent with the
Hyper-V TLB flush hypercalls for example.
This is technically backwards incompatible, but it should be extremely
rare and thus we can treat it as a bugfix, I think.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/kvm/x86.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 4b3681796c75..2fbaa070f741 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7217,6 +7217,11 @@ static int kvm_pv_clock_pairing(struct kvm_vcpu *vcpu, gpa_t paddr,
clock_pairing.flags = 0;
memset(&clock_pairing.pad, 0, sizeof(clock_pairing.pad));
+ paddr = kvm_translate_gpa(vcpu, &vcpu->arch.gva_walk, paddr,
+ PFERR_WRITE_MASK | PFERR_GUEST_FINAL_MASK, NULL, 0);
+ if (paddr == INVALID_GPA)
+ return -KVM_EFAULT;
+
ret = 0;
if (kvm_write_guest(vcpu->kvm, paddr, &clock_pairing,
sizeof(struct kvm_clock_pairing)))
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* Re: [PATCH v2 04/28] KVM: apply nGPA->GPA translation to KVM_HC_CLOCK_PAIRING
2026-09-18 8:15 ` [PATCH v2 04/28] KVM: apply nGPA->GPA translation to KVM_HC_CLOCK_PAIRING Paolo Bonzini
@ 2026-09-18 8:34 ` sashiko-bot
0 siblings, 0 replies; 44+ messages in thread
From: sashiko-bot @ 2026-09-18 8:34 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: kvm
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] kvm: L2 VM escape via unaligned KVM_HC_CLOCK_PAIRING write
--
commit 852f8a2ef0b30977a5795285699a50deabf3525c
Author: Paolo Bonzini <pbonzini@redhat.com>
KVM: apply nGPA->GPA translation to KVM_HC_CLOCK_PAIRING
This commit updates KVM_HC_CLOCK_PAIRING to translate the guest physical
address from an L2 address to an L1 address when running nested.
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 79468ddfe4736..2b81e7a478c45 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -7217,6 +7217,11 @@ static int kvm_pv_clock_pairing(struct kvm_vcpu *vcpu, gpa_t paddr,
> clock_pairing.flags = 0;
> memset(&clock_pairing.pad, 0, sizeof(clock_pairing.pad));
>
> + paddr = kvm_translate_gpa(vcpu, &vcpu->arch.gva_walk, paddr,
> + PFERR_WRITE_MASK | PFERR_GUEST_FINAL_MASK, NULL, 0);
[Severity: Critical]
Does this translation adequately handle the case where the struct crosses a
page boundary?
When kvm_translate_gpa() is called in kvm_pv_clock_pairing(), it only
translates the base L2 GPA. If an untrusted L2 guest provides an unaligned
guest physical address (for example, at offset 4033 in the page), the 64-byte
kvm_clock_pairing struct will span across two L2 pages.
> + if (paddr == INVALID_GPA)
> + return -KVM_EFAULT;
> +
> ret = 0;
> if (kvm_write_guest(vcpu->kvm, paddr, &clock_pairing,
> sizeof(struct kvm_clock_pairing)))
[Severity: Critical]
Could this regression lead to L1 memory corruption when crossing an L2 page
boundary?
Looking at kvm_write_guest() in virt/kvm/kvm_main.c, it writes linearly into
L1 physical address space. When a write hits a page boundary, it increments
the L1 GFN (++gfn) and continues writing to the next contiguous L1 page:
virt/kvm/kvm_main.c:kvm_write_guest() {
...
while ((seg = next_segment(len, offset)) != 0) {
ret = kvm_write_guest_page(kvm, gfn, data, offset, seg);
...
++gfn;
}
...
}
Since contiguous L2 pages are not guaranteed to map to contiguous L1 pages,
incrementing the L1 GFN directly could write the remainder of the 64-byte
struct into an unrelated L1 page. This appears to allow an L2 guest to
overwrite up to 63 bytes of L1 memory.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918081543.139871-1-pbonzini@redhat.com?part=4
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v2 05/28] KVM: x86: Introduce memory fault on invalid hypercalls reads/writes
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
` (3 preceding siblings ...)
2026-09-18 8:15 ` [PATCH v2 04/28] KVM: apply nGPA->GPA translation to KVM_HC_CLOCK_PAIRING Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:33 ` sashiko-bot
2026-09-18 8:15 ` [PATCH v2 06/28] KVM: selftests: test hypercall memory fault exits Paolo Bonzini
` (22 subsequent siblings)
27 siblings, 1 reply; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
Allow userspace to perform arbitrary actions when a hypercall refers to an
invalid address, by exiting with KVM_EXIT_MEMORY_FAULT. This will for
example allow userspace to perform a VTL call.
Co-developed-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
Documentation/virt/kvm/api.rst | 19 ++++
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/hyperv.c | 157 +++++++++++++++++++++++++-------
arch/x86/kvm/x86.c | 38 ++++++--
include/uapi/linux/kvm.h | 1 +
5 files changed, 174 insertions(+), 42 deletions(-)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 37028ce019e3..abc2ff1f8c84 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -8984,6 +8984,25 @@ enabled, cmma can't be enabled anymore and pfmfi and the storage key
interpretation are disabled. If cmma has already been enabled or the
hpage_2g module parameter is not set to 1, -EINVAL is returned.
+7.48 KVM_CAP_HCALL_FAULT_EXIT
+------------------------------------
+
+:Architectures: x86
+:Parameters: args[0] is 0 to disable, 1 to enable
+
+When enabled, KVM checks the memory that is read or written by
+hypercalls (including slow Hyper-V hypercalls and KVM_HC_CLOCK_PAIRING).
+An inaccessible input page causes a KVM_EXIT_MEMORY_FAULT with
+KVM_MEMORY_EXIT_FLAG_READ. An inaccessible or read-only output page causes
+a KVM_EXIT_MEMORY_FAULT with KVM_MEMORY_EXIT_FLAG_WRITE. The reported
+range identifies the page containing the parameter GPA.
+
+Hypercall parameters that are unused by the selected hypercall are not checked.
+
+For Hyper-V, unknown hypercalls are passed to userspace without checking their
+parameter pages. The fault GPA is in the physical address space of the
+VM managed by userspace, after nested GPA translation.
+
8. Other capabilities.
======================
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 683bb8bf43a9..c08781bb0327 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1169,6 +1169,7 @@ struct kvm_arch {
bool has_protected_eoi;
bool has_protected_pmu;
bool pre_fault_allowed;
+ bool hcall_fault_exit;
struct hlist_head *mmu_page_hash;
struct list_head active_mmu_pages;
struct kvm_possible_nx_huge_pages possible_nx_huge_pages[KVM_NR_MMU_TYPES];
diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
index 604651cb2739..9f5adcd26cba 100644
--- a/arch/x86/kvm/hyperv.c
+++ b/arch/x86/kvm/hyperv.c
@@ -2033,7 +2033,68 @@ int kvm_hv_vcpu_flush_tlb(struct kvm_vcpu *vcpu)
return -ENOSPC;
}
-static u64 kvm_hv_flush_tlb(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc)
+static int kvm_hv_hypercall_check_gpa(struct kvm_vcpu *vcpu, gpa_t gpa,
+ bool write)
+{
+ bool writable = true;
+ gfn_t gfn = gpa_to_gfn(gpa);
+ unsigned long addr;
+
+ addr = kvm_vcpu_gfn_to_hva_prot(vcpu, gfn, &writable);
+ if (!kvm_is_error_hva(addr) && (!write || writable))
+ return 0;
+
+ kvm_prepare_memory_fault_exit(vcpu, gfn_to_gpa(gfn), PAGE_SIZE,
+ write, false, false);
+ return -EFAULT;
+}
+
+static unsigned int kvm_hv_hypercall_mem_access(u16 code)
+{
+ switch (code) {
+ case HVCALL_SIGNAL_EVENT:
+ case HVCALL_POST_MESSAGE:
+ case HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST:
+ case HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX:
+ case HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE:
+ case HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX:
+ case HVCALL_SEND_IPI:
+ case HVCALL_SEND_IPI_EX:
+ return KVM_MEMORY_EXIT_FLAG_READ;
+ case HVCALL_POST_DEBUG_DATA:
+ case HVCALL_RETRIEVE_DEBUG_DATA:
+ return KVM_MEMORY_EXIT_FLAG_READ | KVM_MEMORY_EXIT_FLAG_WRITE;
+ case HVCALL_RESET_DEBUG_SESSION:
+ case HV_EXT_CALL_QUERY_CAPABILITIES:
+ return KVM_MEMORY_EXIT_FLAG_WRITE;
+ }
+
+ return 0;
+}
+
+static int kvm_hv_hypercall_check_params(struct kvm_vcpu *vcpu,
+ struct kvm_hv_hcall *hc)
+{
+ unsigned access;
+ int r;
+
+ if (hc->fast || !vcpu->kvm->arch.hcall_fault_exit)
+ return 0;
+
+ access = kvm_hv_hypercall_mem_access(hc->code);
+ if (access & KVM_MEMORY_EXIT_FLAG_READ) {
+ r = kvm_hv_hypercall_check_gpa(vcpu, hc->ingpa, false);
+ if (r)
+ return r;
+ }
+
+ if (access & KVM_MEMORY_EXIT_FLAG_WRITE)
+ return kvm_hv_hypercall_check_gpa(vcpu, hc->outgpa, true);
+
+ return 0;
+}
+
+static s64 kvm_hv_flush_tlb(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc)
{
struct kvm_vcpu_hv *hv_vcpu = to_hv_vcpu(vcpu);
unsigned long *vcpu_mask = hv_vcpu->vcpu_mask;
@@ -2053,6 +2114,19 @@ static u64 kvm_hv_flush_tlb(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc)
struct kvm_vcpu *v;
unsigned long i;
bool all_cpus;
+ int r;
+
+ /* Slow direct hypercalls from L2 provide a nested GPA. */
+ if (!hc->fast) {
+ hc->ingpa = kvm_translate_gpa(vcpu, &vcpu->arch.gva_walk, hc->ingpa,
+ PFERR_GUEST_FINAL_MASK, NULL, 0);
+ if (unlikely(hc->ingpa == INVALID_GPA))
+ return HV_STATUS_INVALID_HYPERCALL_INPUT;
+ }
+
+ r = kvm_hv_hypercall_check_params(vcpu, hc);
+ if (r)
+ return r;
/*
* The Hyper-V TLFS doesn't allow more than HV_MAX_SPARSE_VCPU_BANKS
@@ -2061,20 +2135,6 @@ static u64 kvm_hv_flush_tlb(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc)
*/
BUILD_BUG_ON(KVM_HV_MAX_SPARSE_VCPU_SET_BITS > HV_MAX_SPARSE_VCPU_BANKS);
- /*
- * 'Slow' hypercall's first parameter is the address in guest's memory
- * where hypercall parameters are placed. This is either a GPA or a
- * nested GPA when KVM is handling the call from L2 ('direct' TLB
- * flush). Translate the address here so the memory can be uniformly
- * read with kvm_read_guest().
- */
- if (!hc->fast) {
- hc->ingpa = kvm_translate_gpa(vcpu, &vcpu->arch.gva_walk, hc->ingpa,
- PFERR_GUEST_FINAL_MASK, NULL, 0);
- if (unlikely(hc->ingpa == INVALID_GPA))
- return HV_STATUS_INVALID_HYPERCALL_INPUT;
- }
-
if (hc->code == HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST ||
hc->code == HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE) {
if (hc->fast) {
@@ -2242,7 +2302,7 @@ static void kvm_hv_send_ipi_to_many(struct kvm *kvm, u32 vector,
}
}
-static u64 kvm_hv_send_ipi(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc)
+static int kvm_hv_send_ipi(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc)
{
struct kvm_vcpu_hv *hv_vcpu = to_hv_vcpu(vcpu);
u64 *sparse_banks = hv_vcpu->sparse_banks;
@@ -2252,6 +2312,11 @@ static u64 kvm_hv_send_ipi(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc)
u64 valid_bank_mask;
u32 vector;
bool all_cpus;
+ int r;
+
+ r = kvm_hv_hypercall_check_params(vcpu, hc);
+ if (r)
+ return r;
if (!lapic_in_kernel(vcpu))
return HV_STATUS_INVALID_HYPERCALL_INPUT;
@@ -2432,10 +2497,15 @@ static int kvm_hv_hypercall_complete_userspace(struct kvm_vcpu *vcpu)
return kvm_hv_hypercall_complete(vcpu, vcpu->run->hyperv.u.hcall.result);
}
-static u16 kvm_hvcall_signal_event(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc)
+static int kvm_hvcall_signal_event(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc)
{
struct kvm_hv *hv = to_kvm_hv(vcpu->kvm);
struct eventfd_ctx *eventfd;
+ int ret;
+
+ ret = kvm_hv_hypercall_check_params(vcpu, hc);
+ if (ret)
+ return ret;
if (unlikely(!hc->fast)) {
int ret;
@@ -2547,11 +2617,30 @@ static bool hv_check_hypercall_access(struct kvm_vcpu_hv *hv_vcpu, u16 code)
return true;
}
+static int kvm_hv_hypercall_userspace_exit(struct kvm_vcpu *vcpu,
+ struct kvm_hv_hcall *hc)
+{
+ int r;
+
+ r = kvm_hv_hypercall_check_params(vcpu, hc);
+ if (r)
+ return r;
+
+ vcpu->run->exit_reason = KVM_EXIT_HYPERV;
+ vcpu->run->hyperv.type = KVM_EXIT_HYPERV_HCALL;
+ vcpu->run->hyperv.u.hcall.input = hc->param;
+ vcpu->run->hyperv.u.hcall.params[0] = hc->ingpa;
+ vcpu->run->hyperv.u.hcall.params[1] = hc->outgpa;
+ vcpu->arch.complete_userspace_io = kvm_hv_hypercall_complete_userspace;
+ return 0;
+}
+
int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
{
struct kvm_vcpu_hv *hv_vcpu = to_hv_vcpu(vcpu);
struct kvm_hv_hcall hc;
u64 ret = HV_STATUS_SUCCESS;
+ s64 r;
/*
* hypercall generates UD from non zero cpl and real mode
@@ -2619,7 +2708,10 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
break;
}
- ret = kvm_hvcall_signal_event(vcpu, &hc);
+ r = kvm_hvcall_signal_event(vcpu, &hc);
+ if (r < 0)
+ return r;
+ ret = r;
if (ret != HV_STATUS_INVALID_PORT_ID)
break;
fallthrough; /* maybe userspace knows this conn_id */
@@ -2629,7 +2721,7 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
break;
}
- goto hypercall_userspace_exit;
+ return kvm_hv_hypercall_userspace_exit(vcpu, &hc);
case HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST:
if (unlikely(hc.var_cnt)) {
ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
@@ -2641,7 +2733,10 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
break;
}
- ret = kvm_hv_flush_tlb(vcpu, &hc);
+ r = kvm_hv_flush_tlb(vcpu, &hc);
+ if (r < 0)
+ return r;
+ ret = r;
break;
case HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE:
if (unlikely(hc.var_cnt)) {
@@ -2654,7 +2749,10 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
break;
}
- ret = kvm_hv_flush_tlb(vcpu, &hc);
+ r = kvm_hv_flush_tlb(vcpu, &hc);
+ if (r < 0)
+ return r;
+ ret = r;
break;
case HVCALL_SEND_IPI:
if (unlikely(hc.var_cnt)) {
@@ -2667,7 +2765,10 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
break;
}
- ret = kvm_hv_send_ipi(vcpu, &hc);
+ r = kvm_hv_send_ipi(vcpu, &hc);
+ if (r < 0)
+ return r;
+ ret = r;
break;
case HVCALL_POST_DEBUG_DATA:
case HVCALL_RETRIEVE_DEBUG_DATA:
@@ -2688,14 +2789,14 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
ret = HV_STATUS_OPERATION_DENIED;
break;
}
- goto hypercall_userspace_exit;
+ return kvm_hv_hypercall_userspace_exit(vcpu, &hc);
}
case HV_EXT_CALL_QUERY_CAPABILITIES ... HV_EXT_CALL_MAX:
if (unlikely(hc.fast)) {
ret = HV_STATUS_INVALID_PARAMETER;
break;
}
- goto hypercall_userspace_exit;
+ return kvm_hv_hypercall_userspace_exit(vcpu, &hc);
default:
ret = HV_STATUS_INVALID_HYPERCALL_CODE;
break;
@@ -2704,14 +2805,6 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
hypercall_complete:
return kvm_hv_hypercall_complete(vcpu, ret);
-hypercall_userspace_exit:
- vcpu->run->exit_reason = KVM_EXIT_HYPERV;
- vcpu->run->hyperv.type = KVM_EXIT_HYPERV_HCALL;
- vcpu->run->hyperv.u.hcall.input = hc.param;
- vcpu->run->hyperv.u.hcall.params[0] = hc.ingpa;
- vcpu->run->hyperv.u.hcall.params[1] = hc.outgpa;
- vcpu->arch.complete_userspace_io = kvm_hv_hypercall_complete_userspace;
- return 0;
}
void kvm_hv_init_vm(struct kvm *kvm)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 2fbaa070f741..c10b3fd48b65 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2242,6 +2242,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_HYPERV_ENFORCE_CPUID:
case KVM_CAP_SYS_HYPERV_CPUID:
#endif
+ case KVM_CAP_HCALL_FAULT_EXIT:
case KVM_CAP_PCI_SEGMENT:
case KVM_CAP_DEBUGREGS:
case KVM_CAP_X86_ROBUST_SINGLESTEP:
@@ -4210,6 +4211,10 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
mutex_unlock(&kvm->lock);
break;
}
+ case KVM_CAP_HCALL_FAULT_EXIT:
+ kvm->arch.hcall_fault_exit = cap->args[0];
+ r = 0;
+ break;
default:
r = -EINVAL;
break;
@@ -7191,25 +7196,27 @@ EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_x86_vendor_exit);
#ifdef CONFIG_X86_64
static int kvm_pv_clock_pairing(struct kvm_vcpu *vcpu, gpa_t paddr,
- unsigned long clock_type)
+ unsigned long clock_type, unsigned long *ret)
{
struct kvm_clock_pairing clock_pairing;
struct timespec64 ts;
+ bool writable;
+ unsigned long hva;
u64 cycle;
- int ret;
+ *ret = -KVM_EOPNOTSUPP;
if (clock_type != KVM_CLOCK_PAIRING_WALLCLOCK)
- return -KVM_EOPNOTSUPP;
+ return 0;
/*
* When tsc is in permanent catchup mode guests won't be able to use
* pvclock_read_retry loop to get consistent view of pvclock
*/
if (vcpu->arch.tsc_always_catchup)
- return -KVM_EOPNOTSUPP;
+ return 0;
if (!kvm_get_walltime_and_clockread(&ts, &cycle))
- return -KVM_EOPNOTSUPP;
+ return 0;
clock_pairing.sec = ts.tv_sec;
clock_pairing.nsec = ts.tv_nsec;
@@ -7217,17 +7224,27 @@ static int kvm_pv_clock_pairing(struct kvm_vcpu *vcpu, gpa_t paddr,
clock_pairing.flags = 0;
memset(&clock_pairing.pad, 0, sizeof(clock_pairing.pad));
+ *ret = -KVM_EFAULT;
paddr = kvm_translate_gpa(vcpu, &vcpu->arch.gva_walk, paddr,
PFERR_WRITE_MASK | PFERR_GUEST_FINAL_MASK, NULL, 0);
if (paddr == INVALID_GPA)
- return -KVM_EFAULT;
+ return 0;
+
+ if (vcpu->kvm->arch.hcall_fault_exit) {
+ hva = kvm_vcpu_gfn_to_hva_prot(vcpu, gpa_to_gfn(paddr), &writable);
+ if (kvm_is_error_hva(hva) || !writable) {
+ kvm_prepare_memory_fault_exit(vcpu, paddr & PAGE_MASK, PAGE_SIZE,
+ true, false, false);
+ return -EFAULT;
+ }
+ }
- ret = 0;
if (kvm_write_guest(vcpu->kvm, paddr, &clock_pairing,
sizeof(struct kvm_clock_pairing)))
- ret = -KVM_EFAULT;
+ return 0;
- return ret;
+ *ret = 0;
+ return 0;
}
#endif
@@ -7385,7 +7402,8 @@ int ____kvm_emulate_hypercall(struct kvm_vcpu *vcpu, int cpl,
break;
#ifdef CONFIG_X86_64
case KVM_HC_CLOCK_PAIRING:
- ret = kvm_pv_clock_pairing(vcpu, a0, a1);
+ if (kvm_pv_clock_pairing(vcpu, a0, a1, &ret))
+ return -EFAULT;
break;
#endif
case KVM_HC_SEND_IPI:
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 15a3090f067e..c23f1ea62eaf 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1002,6 +1002,7 @@ struct kvm_enable_cap {
#define KVM_CAP_S390_HPAGE_2G 249
#define KVM_CAP_PPC_COMPAT_CAPS 250
#define KVM_CAP_ARM_PMU_V3_STRICT 251
+#define KVM_CAP_HCALL_FAULT_EXIT 252
struct kvm_irq_routing_irqchip {
__u32 irqchip;
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* Re: [PATCH v2 05/28] KVM: x86: Introduce memory fault on invalid hypercalls reads/writes
2026-09-18 8:15 ` [PATCH v2 05/28] KVM: x86: Introduce memory fault on invalid hypercalls reads/writes Paolo Bonzini
@ 2026-09-18 8:33 ` sashiko-bot
0 siblings, 0 replies; 44+ messages in thread
From: sashiko-bot @ 2026-09-18 8:33 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: kvm
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] x86/hyperv: spurious memory fault on HVCALL_SIGNAL_EVENT due to double validation
--
commit 9e7f4342fa28fd49b13df88579465f8fb51e4a93
Author: Paolo Bonzini <pbonzini@redhat.com>
KVM: x86: Introduce memory fault on invalid hypercalls reads/writes
This commit allows userspace to perform arbitrary actions when a hypercall
refers to an invalid address, by exiting with KVM_EXIT_MEMORY_FAULT.
> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
> index 604651cb27399..9f5adcd26cba3 100644
> --- a/arch/x86/kvm/hyperv.c
> +++ b/arch/x86/kvm/hyperv.c
> @@ -2547,11 +2617,30 @@ static bool hv_check_hypercall_access(struct kvm_vcpu_hv *hv_vcpu, u16 code)
> return true;
> }
>
> +static int kvm_hv_hypercall_userspace_exit(struct kvm_vcpu *vcpu,
> + struct kvm_hv_hcall *hc)
> +{
> + int r;
> +
> + r = kvm_hv_hypercall_check_params(vcpu, hc);
> + if (r)
> + return r;
[Severity: High]
Does this code perform a physical memory validation on hc->ingpa, which has
already been overwritten with the connection ID for slow hypercalls?
When a guest makes a slow HVCALL_SIGNAL_EVENT hypercall with a connection ID
that is valid in userspace but not registered in the kernel conn_to_evt,
kvm_hvcall_signal_event() reads the connection ID and overwrites hc->ingpa:
kvm_hvcall_signal_event() {
if (unlikely(!hc->fast)) {
...
ret = kvm_vcpu_read_guest(vcpu, gpa,
&hc->ingpa, sizeof(hc->ingpa));
...
}
It then returns HV_STATUS_INVALID_PORT_ID, and the switch statement in
kvm_hv_hypercall() falls through to HVCALL_POST_MESSAGE and calls
kvm_hv_hypercall_userspace_exit().
Will this cause a spurious KVM_EXIT_MEMORY_FAULT instead of a normal
KVM_EXIT_HYPERV because kvm_hv_hypercall_check_params() incorrectly
re-validates the overwritten hc->ingpa as a GPA?
> +
> + vcpu->run->exit_reason = KVM_EXIT_HYPERV;
> + vcpu->run->hyperv.type = KVM_EXIT_HYPERV_HCALL;
> + vcpu->run->hyperv.u.hcall.input = hc->param;
> + vcpu->run->hyperv.u.hcall.params[0] = hc->ingpa;
> + vcpu->run->hyperv.u.hcall.params[1] = hc->outgpa;
> + vcpu->arch.complete_userspace_io = kvm_hv_hypercall_complete_userspace;
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918081543.139871-1-pbonzini@redhat.com?part=5
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v2 06/28] KVM: selftests: test hypercall memory fault exits
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
` (4 preceding siblings ...)
2026-09-18 8:15 ` [PATCH v2 05/28] KVM: x86: Introduce memory fault on invalid hypercalls reads/writes Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:24 ` sashiko-bot
2026-09-18 8:15 ` [PATCH v2 07/28] KVM: x86/mmu: intersect writability from __kvm_faultin_pfn with fault->map_writable Paolo Bonzini
` (21 subsequent siblings)
27 siblings, 1 reply; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
Cover various scenarios where hypercalls are invoked with invalid or
read-only GPAs, and check that they exit to userspace.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
tools/testing/selftests/kvm/Makefile.kvm | 1 +
tools/testing/selftests/kvm/x86/hcall_fault.c | 236 ++++++++++++++++++
.../testing/selftests/kvm/x86/hyperv_evmcs.c | 4 +
.../selftests/kvm/x86/hyperv_svm_test.c | 2 +
4 files changed, 243 insertions(+)
create mode 100644 tools/testing/selftests/kvm/x86/hcall_fault.c
diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm
index 96bab7002d39..6e2bbf743eaa 100644
--- a/tools/testing/selftests/kvm/Makefile.kvm
+++ b/tools/testing/selftests/kvm/Makefile.kvm
@@ -79,6 +79,7 @@ TEST_GEN_PROGS_x86 += x86/evmcs_smm_controls_test
TEST_GEN_PROGS_x86 += x86/exit_on_emulation_failure_test
TEST_GEN_PROGS_x86 += x86/fastops_test
TEST_GEN_PROGS_x86 += x86/fix_hypercall_test
+TEST_GEN_PROGS_x86 += x86/hcall_fault
TEST_GEN_PROGS_x86 += x86/hwcr_msr_test
TEST_GEN_PROGS_x86 += x86/hyperv_clock
TEST_GEN_PROGS_x86 += x86/hyperv_cpuid
diff --git a/tools/testing/selftests/kvm/x86/hcall_fault.c b/tools/testing/selftests/kvm/x86/hcall_fault.c
new file mode 100644
index 000000000000..63e38c87616f
--- /dev/null
+++ b/tools/testing/selftests/kvm/x86/hcall_fault.c
@@ -0,0 +1,236 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include <errno.h>
+
+#include "kvm_util.h"
+#include "processor.h"
+#include "hyperv.h"
+
+#define TEST_MEM_GPA 0x100000000ull
+#define READONLY_GPA (TEST_MEM_GPA + PAGE_SIZE)
+#define UNMAPPED_IN_GPA (TEST_MEM_GPA + 2 * PAGE_SIZE)
+#define UNMAPPED_OUT_GPA (TEST_MEM_GPA + 3 * PAGE_SIZE)
+
+struct hcall_test {
+ /* TEST_MEM_GPA in the guest */
+ u64 control;
+ u64 ingpa;
+ u64 outgpa;
+ u64 expected_status;
+ u8 unused[PAGE_SIZE - 32];
+
+ /* READONLY_GPA in the guest */
+ u8 readonly_data[];
+};
+
+#define HV_FLUSH_ALL_PROCESSORS BIT(0)
+#define HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES BIT(1)
+
+/* HvFlushVirtualAddressSpace, HvFlushVirtualAddressList hypercalls */
+struct hv_tlb_flush {
+ u64 address_space;
+ u64 flags;
+ u64 processor_mask;
+ u64 gva_list[];
+} __packed;
+
+static void guest_code(gpa_t hcall_page, struct hcall_test *test)
+{
+ u64 result;
+ u8 vector;
+
+ wrmsr(HV_X64_MSR_GUEST_OS_ID, HYPERV_LINUX_OS_ID);
+ wrmsr(HV_X64_MSR_HYPERCALL, hcall_page);
+
+ vector = __hyperv_hypercall(test->control, test->ingpa, test->outgpa, &result);
+ GUEST_ASSERT(!vector);
+ GUEST_ASSERT_EQ(result & 0xffff, test->expected_status);
+ GUEST_DONE();
+}
+
+static void clock_pairing_guest(gpa_t gpa)
+{
+ kvm_hypercall(KVM_HC_CLOCK_PAIRING, gpa, KVM_CLOCK_PAIRING_WALLCLOCK, 0, 0);
+ GUEST_DONE();
+}
+
+static struct kvm_vm *create_vm(struct kvm_vcpu **vcpu, struct hcall_test **test,
+ gpa_t *hcall_page_gpa)
+{
+ gva_t hcall_page, test_gva;
+ struct kvm_vm *vm;
+
+ vm = vm_create_with_one_vcpu(vcpu, guest_code);
+ vcpu_set_hv_cpuid(*vcpu);
+ vm_enable_cap(vm, KVM_CAP_HCALL_FAULT_EXIT, 1);
+
+ hcall_page = vm_alloc_page(vm);
+ memset(addr_gva2hva(vm, hcall_page), 0, PAGE_SIZE);
+ *hcall_page_gpa = addr_gva2gpa(vm, hcall_page);
+
+ vm_userspace_mem_region_add(vm, VM_MEM_SRC_ANONYMOUS, TEST_MEM_GPA,
+ 10, 1, 0);
+ memset(addr_gpa2hva(vm, TEST_MEM_GPA), 0, PAGE_SIZE);
+
+ vm_userspace_mem_region_add(vm, VM_MEM_SRC_ANONYMOUS, READONLY_GPA,
+ 11, 1, KVM_MEM_READONLY);
+ memset(addr_gpa2hva(vm, READONLY_GPA), 0, PAGE_SIZE);
+
+ test_gva = vm_unused_gva_gap(vm, PAGE_SIZE * 2, 1 << 24);
+ for (int i = 0; i < 2; i++)
+ virt_pg_map(vm, test_gva + PAGE_SIZE * i, TEST_MEM_GPA + PAGE_SIZE * i);
+ *test = addr_gva2hva(vm, test_gva);
+
+ vcpu_args_set(*vcpu, 2, *hcall_page_gpa, test_gva);
+ return vm;
+}
+
+static void run_vm(struct kvm_vcpu *vcpu)
+{
+ struct ucall uc;
+
+ vcpu_run(vcpu);
+ TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_IO);
+
+ switch (get_ucall(vcpu, &uc)) {
+ case UCALL_ABORT:
+ REPORT_GUEST_ASSERT(uc);
+ break;
+ case UCALL_DONE:
+ break;
+ default:
+ TEST_FAIL("Unexpected ucall: %lu", uc.cmd);
+ }
+}
+
+static void test_unused_gpas(void)
+{
+ struct hcall_test *test;
+ struct kvm_vcpu *vcpu;
+ struct kvm_vm *vm;
+ gpa_t hcall_page;
+
+ vm = create_vm(&vcpu, &test, &hcall_page);
+ test->control = HVCALL_NOTIFY_LONG_SPIN_WAIT;
+ test->ingpa = UNMAPPED_IN_GPA;
+ test->outgpa = UNMAPPED_OUT_GPA;
+ test->expected_status = HV_STATUS_SUCCESS;
+ run_vm(vcpu);
+ kvm_vm_free(vm);
+
+ vm = create_vm(&vcpu, &test, &hcall_page);
+ test->control = 0xbeef;
+ test->ingpa = UNMAPPED_IN_GPA;
+ test->outgpa = UNMAPPED_OUT_GPA;
+ test->expected_status = HV_STATUS_INVALID_HYPERCALL_CODE;
+ run_vm(vcpu);
+ kvm_vm_free(vm);
+}
+
+static void assert_memory_fault(struct kvm_vcpu *vcpu, gpa_t gpa, u64 flags)
+{
+ int r;
+
+ r = _vcpu_run(vcpu);
+ TEST_ASSERT(r == -1 && errno == EFAULT, KVM_IOCTL_ERROR(KVM_RUN, r));
+ TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_MEMORY_FAULT);
+ TEST_ASSERT_EQ(vcpu->run->memory_fault.flags, flags);
+ TEST_ASSERT_EQ(vcpu->run->memory_fault.gpa, gpa & PAGE_MASK);
+ TEST_ASSERT_EQ(vcpu->run->memory_fault.size, PAGE_SIZE);
+}
+
+/* Read-only hypercalls, read-only inputs, valid/invalid argument */
+static void test_readonly_input(void)
+{
+ struct hv_tlb_flush *flush;
+ struct hcall_test *test;
+ struct kvm_vcpu *vcpu;
+ struct kvm_vm *vm;
+ gpa_t hcall_page;
+
+ vm = create_vm(&vcpu, &test, &hcall_page);
+ flush = (struct hv_tlb_flush *)&test->readonly_data;
+ flush->flags = HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES | HV_FLUSH_ALL_PROCESSORS;
+ flush->processor_mask = 0;
+ test->control = HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE;
+ test->ingpa = READONLY_GPA;
+ test->outgpa = UNMAPPED_OUT_GPA;
+ test->expected_status = HV_STATUS_SUCCESS;
+ run_vm(vcpu);
+ kvm_vm_free(vm);
+
+ /* fails immediately because it requires SynIC */
+ vm = create_vm(&vcpu, &test, &hcall_page);
+ test->control = HVCALL_POST_MESSAGE;
+ test->ingpa = UNMAPPED_IN_GPA;
+ test->outgpa = UNMAPPED_OUT_GPA;
+ test->expected_status = HV_STATUS_INVALID_HYPERCALL_INPUT;
+ run_vm(vcpu);
+ kvm_vm_free(vm);
+}
+
+/* Read-only hypercall, unmapped input */
+static void test_input_fault(void)
+{
+ struct hcall_test *test;
+ struct kvm_vcpu *vcpu;
+ struct kvm_vm *vm;
+ gpa_t hcall_page;
+
+ vm = create_vm(&vcpu, &test, &hcall_page);
+ test->control = HVCALL_SIGNAL_EVENT;
+ test->ingpa = UNMAPPED_IN_GPA;
+ test->outgpa = UNMAPPED_OUT_GPA;
+ assert_memory_fault(vcpu, test->ingpa, KVM_MEMORY_EXIT_FLAG_READ);
+ kvm_vm_free(vm);
+}
+
+/* Read-write hypercall, unmapped or readonly input and output */
+static void test_output_fault(bool readonly_in, bool readonly_out)
+{
+ struct hcall_test *test;
+ struct kvm_vcpu *vcpu;
+ struct kvm_vm *vm;
+ gpa_t hcall_page;
+
+ vm = create_vm(&vcpu, &test, &hcall_page);
+ test->control = HV_EXT_CALL_QUERY_CAPABILITIES;
+ test->ingpa = readonly_in ? READONLY_GPA : UNMAPPED_IN_GPA;
+ test->outgpa = readonly_out ? READONLY_GPA : UNMAPPED_OUT_GPA;
+
+ assert_memory_fault(vcpu, test->outgpa, KVM_MEMORY_EXIT_FLAG_WRITE);
+ kvm_vm_free(vm);
+}
+
+static void test_clock_pairing_fault(bool readonly)
+{
+ struct kvm_vcpu *vcpu;
+ struct kvm_vm *vm;
+ gpa_t gpa;
+
+ /* Unlike create_vm do not enable Hyper-V hypercalls. */
+ vm = vm_create_with_one_vcpu(&vcpu, clock_pairing_guest);
+ vm_enable_cap(vm, KVM_CAP_HCALL_FAULT_EXIT, 1);
+ gpa = readonly ? READONLY_GPA : UNMAPPED_OUT_GPA;
+ vcpu_args_set(vcpu, 1, gpa);
+
+ assert_memory_fault(vcpu, gpa, KVM_MEMORY_EXIT_FLAG_WRITE);
+ kvm_vm_free(vm);
+}
+
+int main(void)
+{
+ TEST_REQUIRE(kvm_has_cap(KVM_CAP_HYPERV_CPUID));
+ TEST_REQUIRE(kvm_has_cap(KVM_CAP_HCALL_FAULT_EXIT));
+ TEST_REQUIRE(kvm_cpuid_has(kvm_get_supported_hv_cpuid(),
+ HV_ENABLE_EXTENDED_HYPERCALLS));
+
+ test_unused_gpas();
+ test_readonly_input();
+ test_input_fault();
+ test_output_fault(false, false);
+ test_output_fault(true, false);
+ test_output_fault(false, true);
+ test_clock_pairing_fault(false);
+ test_clock_pairing_fault(true);
+ return 0;
+}
diff --git a/tools/testing/selftests/kvm/x86/hyperv_evmcs.c b/tools/testing/selftests/kvm/x86/hyperv_evmcs.c
index fa80bc78aef7..cd8d8acb2419 100644
--- a/tools/testing/selftests/kvm/x86/hyperv_evmcs.c
+++ b/tools/testing/selftests/kvm/x86/hyperv_evmcs.c
@@ -216,6 +216,8 @@ static struct kvm_vcpu *save_restore_vm(struct kvm_vm *vm,
/* Restore state in a new VM. */
vcpu = vm_recreate_with_one_vcpu(vm);
+ if (kvm_has_cap(KVM_CAP_HCALL_FAULT_EXIT))
+ vm_enable_cap(vm, KVM_CAP_HCALL_FAULT_EXIT, 1);
vm_enable_ept(vm);
vcpu_set_hv_cpuid(vcpu);
vcpu_enable_evmcs(vcpu);
@@ -247,6 +249,8 @@ int main(int argc, char *argv[])
TEST_REQUIRE(kvm_cpu_has_ept());
vm = vm_create_with_one_vcpu(&vcpu, guest_code);
+ if (kvm_has_cap(KVM_CAP_HCALL_FAULT_EXIT))
+ vm_enable_cap(vm, KVM_CAP_HCALL_FAULT_EXIT, 1);
vm_enable_ept(vm);
hcall_page = vm_alloc_pages(vm, 1);
diff --git a/tools/testing/selftests/kvm/x86/hyperv_svm_test.c b/tools/testing/selftests/kvm/x86/hyperv_svm_test.c
index 18f0ad6debd8..ecad242e6623 100644
--- a/tools/testing/selftests/kvm/x86/hyperv_svm_test.c
+++ b/tools/testing/selftests/kvm/x86/hyperv_svm_test.c
@@ -162,6 +162,8 @@ int main(int argc, char *argv[])
/* Create VM */
vm = vm_create_with_one_vcpu(&vcpu, guest_code);
+ if (kvm_has_cap(KVM_CAP_HCALL_FAULT_EXIT))
+ vm_enable_cap(vm, KVM_CAP_HCALL_FAULT_EXIT, 1);
vm_enable_npt(vm);
vcpu_set_hv_cpuid(vcpu);
vcpu_alloc_svm(vm, &nested_gva);
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* Re: [PATCH v2 06/28] KVM: selftests: test hypercall memory fault exits
2026-09-18 8:15 ` [PATCH v2 06/28] KVM: selftests: test hypercall memory fault exits Paolo Bonzini
@ 2026-09-18 8:24 ` sashiko-bot
0 siblings, 0 replies; 44+ messages in thread
From: sashiko-bot @ 2026-09-18 8:24 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: kvm
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] kvm: selftests: host OOB write in test_readonly_input()
- [Medium] kvm: selftests: missing read-only memory map in test_clock_pairing_fault()
--
commit 363dccb0211d2629dd610b0d28c041e51635155e
Author: Paolo Bonzini <pbonzini@redhat.com>
KVM: selftests: test hypercall memory fault exits
This commit introduces selftests for KVM hypercall memory faults. It verifies
that hypercalls with invalid or read-only guest physical addresses exit to
userspace correctly.
> diff --git a/tools/testing/selftests/kvm/x86/hcall_fault.c b/tools/testing/selftests/kvm/x86/hcall_fault.c
> new file mode 100644
> index 0000000000000..63e38c87616f9
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/x86/hcall_fault.c
[ ... ]
> +/* Read-only hypercalls, read-only inputs, valid/invalid argument */
> +static void test_readonly_input(void)
> +{
> + struct hv_tlb_flush *flush;
> + struct hcall_test *test;
> + struct kvm_vcpu *vcpu;
> + struct kvm_vm *vm;
> + gpa_t hcall_page;
> +
> + vm = create_vm(&vcpu, &test, &hcall_page);
> + flush = (struct hv_tlb_flush *)&test->readonly_data;
> + flush->flags = HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES | HV_FLUSH_ALL_PROCESSORS;
> + flush->processor_mask = 0;
[Severity: Medium]
Will this result in an out-of-bounds host memory write?
The test allocates two separate 1-page memslots for TEST_MEM_GPA and
READONLY_GPA. In the guest, they are mapped contiguously to test_gva. However,
create_vm() gets the host virtual address of only the first page and assigns
it to the test pointer.
By accessing test->readonly_data, does this write past the 1-page host
allocation of the first memslot?
> + test->control = HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE;
> + test->ingpa = READONLY_GPA;
> + test->outgpa = UNMAPPED_OUT_GPA;
[ ... ]
> +static void test_clock_pairing_fault(bool readonly)
> +{
> + struct kvm_vcpu *vcpu;
> + struct kvm_vm *vm;
> + gpa_t gpa;
> +
> + /* Unlike create_vm do not enable Hyper-V hypercalls. */
> + vm = vm_create_with_one_vcpu(&vcpu, clock_pairing_guest);
> + vm_enable_cap(vm, KVM_CAP_HCALL_FAULT_EXIT, 1);
> + gpa = readonly ? READONLY_GPA : UNMAPPED_OUT_GPA;
[Severity: Medium]
When readonly is true, does this inadvertently test an unmapped write fault
instead of a read-only write fault?
Since test_clock_pairing_fault() creates a new VM with
vm_create_with_one_vcpu() instead of using create_vm(), it appears
READONLY_GPA is never actually mapped into the guest as a read-only memslot.
Will KVM treat READONLY_GPA as completely unmapped memory here, missing the
intended coverage for read-only memory faults?
> + vcpu_args_set(vcpu, 1, gpa);
> +
> + assert_memory_fault(vcpu, gpa, KVM_MEMORY_EXIT_FLAG_WRITE);
> + kvm_vm_free(vm);
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918081543.139871-1-pbonzini@redhat.com?part=6
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v2 07/28] KVM: x86/mmu: intersect writability from __kvm_faultin_pfn with fault->map_writable
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
` (5 preceding siblings ...)
2026-09-18 8:15 ` [PATCH v2 06/28] KVM: selftests: test hypercall memory fault exits Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:15 ` [PATCH v2 08/28] KVM: x86/mmu: Extend map_writable to a full ACC_* mask Paolo Bonzini
` (20 subsequent siblings)
27 siblings, 0 replies; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
fault->map_writable is currently a pure output of __kvm_faultin_pfn(),
which is the only thing that restricts it. This will no longer hold once
memory protections derived from memory attributes are applied: those
compute their own access permissions that combine with those from
__kvm_faultin_pfn().
Applying them *before* faulting in the pfn lets a fault that violates
the attributes exit to userspace without the cost of gup and/or an
async #PF; but it means that permissions will then be restricted in two
independent steps, first by memory attributes and then by __kvm_faultin_pfn().
Switch fault->map_writable to that model by letting kvm_mmu_faultin_pfn()
only clear bits rather than assign them.
No functional change intended: nothing writes fault->map_writable between
the initializer and __kvm_mmu_faultin_pfn() yet, so the AND is equivalent
to the assignment it replaces.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/kvm/mmu/mmu.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 064ecc33b926..5996468b7120 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -4634,7 +4634,7 @@ static int kvm_mmu_faultin_pfn_gmem(struct kvm_vcpu *vcpu,
return r;
}
- fault->map_writable = !(fault->slot->flags & KVM_MEM_READONLY);
+ fault->map_writable &= !(fault->slot->flags & KVM_MEM_READONLY);
fault->max_level = kvm_max_level_for_order(max_order);
return RET_PF_CONTINUE;
@@ -4644,13 +4644,14 @@ static int __kvm_mmu_faultin_pfn(struct kvm_vcpu *vcpu,
struct kvm_page_fault *fault)
{
unsigned int foll = fault->write ? FOLL_WRITE : 0;
+ bool writable;
if (fault->is_private || kvm_memslot_is_gmem_only(fault->slot))
return kvm_mmu_faultin_pfn_gmem(vcpu, fault);
foll |= FOLL_NOWAIT;
fault->pfn = __kvm_faultin_pfn(fault->slot, fault->gfn, foll,
- &fault->map_writable, &fault->refcounted_page);
+ &writable, &fault->refcounted_page);
/*
* If resolving the page failed because I/O is needed to fault-in the
@@ -4659,7 +4660,7 @@ static int __kvm_mmu_faultin_pfn(struct kvm_vcpu *vcpu,
* other failures are terminal, i.e. retrying won't help.
*/
if (fault->pfn != KVM_PFN_ERR_NEEDS_IO)
- return RET_PF_CONTINUE;
+ goto out_pf_continue;
if (!fault->prefetch && kvm_can_do_async_pf(vcpu)) {
trace_kvm_try_async_get_page(fault->addr, fault->gfn);
@@ -4680,8 +4681,10 @@ static int __kvm_mmu_faultin_pfn(struct kvm_vcpu *vcpu,
foll |= FOLL_INTERRUPTIBLE;
foll &= ~FOLL_NOWAIT;
fault->pfn = __kvm_faultin_pfn(fault->slot, fault->gfn, foll,
- &fault->map_writable, &fault->refcounted_page);
+ &writable, &fault->refcounted_page);
+out_pf_continue:
+ fault->map_writable &= writable;
return RET_PF_CONTINUE;
}
@@ -5000,6 +5003,7 @@ static int kvm_mmu_do_page_fault(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa,
.is_private = err & PFERR_PRIVATE_ACCESS,
.pfn = KVM_PFN_ERR_FAULT,
+ .map_writable = true,
};
int r;
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v2 08/28] KVM: x86/mmu: Extend map_writable to a full ACC_* mask
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
` (6 preceding siblings ...)
2026-09-18 8:15 ` [PATCH v2 07/28] KVM: x86/mmu: intersect writability from __kvm_faultin_pfn with fault->map_writable Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:15 ` [PATCH v2 09/28] KVM: x86/mmu: Init memslot hugepage information for non-private_mem VMs too Paolo Bonzini
` (19 subsequent siblings)
27 siblings, 0 replies; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
Support for memory protection attributes opens the door to installing
non-executable mappings. Instead of introducing yet another member in
struct kvm_page_fault and another argument to make_spte(), make the
existing member map_writable a mask of ACC_* bits. This also avoids the
need for make_spte() to map a single bool to either the NX bit or
the XS/XU bits together.
Unlike for mappings that are not writable because the fault did
not request write premission, it is not not necessary to track
executability for these SPTEs; the gfn is always available and it will
be possible to access the attributes directly in FNAME(sync_spte).
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/kvm/mmu/mmu.c | 21 ++++++++++++---------
arch/x86/kvm/mmu/mmu_internal.h | 2 +-
arch/x86/kvm/mmu/paging_tmpl.h | 8 +++++---
arch/x86/kvm/mmu/spte.c | 12 ++++++------
arch/x86/kvm/mmu/spte.h | 2 +-
arch/x86/kvm/mmu/tdp_mmu.c | 2 +-
6 files changed, 26 insertions(+), 21 deletions(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 5996468b7120..b72ccbee0d86 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -3105,7 +3105,7 @@ static int mmu_set_spte(struct kvm_vcpu *vcpu, struct kvm_memory_slot *slot,
u64 spte;
/* Prefetching always gets a writable pfn. */
- bool host_writable = !fault || fault->map_writable;
+ unsigned host_access = fault ? fault->host_access : ACC_ALL;
bool prefetch = !fault || fault->prefetch;
bool write_fault = fault && fault->write;
@@ -3142,7 +3142,7 @@ static int mmu_set_spte(struct kvm_vcpu *vcpu, struct kvm_memory_slot *slot,
}
wrprot = make_spte(vcpu, sp, slot, pte_access, gfn, pfn, *sptep, prefetch,
- false, host_writable, &spte);
+ false, host_access, &spte);
if (*sptep == spte) {
ret = RET_PF_SPURIOUS;
@@ -3589,7 +3589,7 @@ static int kvm_handle_noslot_fault(struct kvm_vcpu *vcpu,
fault->slot = NULL;
fault->pfn = KVM_PFN_NOSLOT;
- fault->map_writable = false;
+ fault->host_access = 0;
/*
* If MMIO caching is disabled, emulate immediately without
@@ -4614,7 +4614,8 @@ static void kvm_mmu_finish_page_fault(struct kvm_vcpu *vcpu,
struct kvm_page_fault *fault, int r)
{
kvm_release_faultin_page(vcpu->kvm, fault->refcounted_page,
- r == RET_PF_RETRY, fault->map_writable);
+ r == RET_PF_RETRY,
+ !!(fault->host_access & ACC_WRITE_MASK));
}
static int kvm_mmu_faultin_pfn_gmem(struct kvm_vcpu *vcpu,
@@ -4634,9 +4635,10 @@ static int kvm_mmu_faultin_pfn_gmem(struct kvm_vcpu *vcpu,
return r;
}
- fault->map_writable &= !(fault->slot->flags & KVM_MEM_READONLY);
- fault->max_level = kvm_max_level_for_order(max_order);
+ if (fault->slot->flags & KVM_MEM_READONLY)
+ fault->host_access &= ~ACC_WRITE_MASK;
+ fault->max_level = kvm_max_level_for_order(max_order);
return RET_PF_CONTINUE;
}
@@ -4684,7 +4686,8 @@ static int __kvm_mmu_faultin_pfn(struct kvm_vcpu *vcpu,
&writable, &fault->refcounted_page);
out_pf_continue:
- fault->map_writable &= writable;
+ if (!writable)
+ fault->host_access &= ~ACC_WRITE_MASK;
return RET_PF_CONTINUE;
}
@@ -5003,7 +5006,7 @@ static int kvm_mmu_do_page_fault(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa,
.is_private = err & PFERR_PRIVATE_ACCESS,
.pfn = KVM_PFN_ERR_FAULT,
- .map_writable = true,
+ .host_access = ACC_ALL,
};
int r;
@@ -5197,7 +5200,7 @@ int kvm_tdp_mmu_map_private_pfn(struct kvm_vcpu *vcpu, gfn_t gfn, kvm_pfn_t pfn)
.gfn = gfn,
.slot = kvm_vcpu_gfn_to_memslot(vcpu, gfn),
.pfn = pfn,
- .map_writable = true,
+ .host_access = ACC_ALL,
};
struct kvm *kvm = vcpu->kvm;
int r;
diff --git a/arch/x86/kvm/mmu/mmu_internal.h b/arch/x86/kvm/mmu/mmu_internal.h
index c29002c60126..00215b9f309f 100644
--- a/arch/x86/kvm/mmu/mmu_internal.h
+++ b/arch/x86/kvm/mmu/mmu_internal.h
@@ -280,7 +280,7 @@ struct kvm_page_fault {
unsigned long mmu_seq;
kvm_pfn_t pfn;
struct page *refcounted_page;
- bool map_writable;
+ u8 host_access;
/*
* Indicates the guest is trying to write a gfn that contains one or
diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h
index 27427e7f22fa..e6ec14165f40 100644
--- a/arch/x86/kvm/mmu/paging_tmpl.h
+++ b/arch/x86/kvm/mmu/paging_tmpl.h
@@ -935,7 +935,7 @@ static gpa_t FNAME(gva_to_gpa)(struct kvm_vcpu *vcpu, struct kvm_pagewalk *w,
*/
static int FNAME(sync_spte)(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp, int i)
{
- bool host_writable;
+ u8 host_access;
gpa_t first_pte_gpa;
u64 *sptep, spte;
struct kvm_memory_slot *slot;
@@ -992,11 +992,13 @@ static int FNAME(sync_spte)(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp, int
sptep = &sp->spt[i];
spte = *sptep;
- host_writable = spte & shadow_host_writable_mask;
+ host_access = ACC_ALL;
+ if (!(spte & shadow_host_writable_mask))
+ host_access &= ~ACC_WRITE_MASK;
slot = kvm_vcpu_gfn_to_memslot(vcpu, gfn);
make_spte(vcpu, sp, slot, pte_access, gfn,
spte_to_pfn(spte), spte, true, true,
- host_writable, &spte);
+ host_access, &spte);
/*
* There is no need to mark the pfn dirty, as the new protections must
diff --git a/arch/x86/kvm/mmu/spte.c b/arch/x86/kvm/mmu/spte.c
index 5fc27e9733b3..1434164fa372 100644
--- a/arch/x86/kvm/mmu/spte.c
+++ b/arch/x86/kvm/mmu/spte.c
@@ -189,7 +189,7 @@ bool make_spte(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp,
const struct kvm_memory_slot *slot,
unsigned int pte_access, gfn_t gfn, kvm_pfn_t pfn,
u64 old_spte, bool prefetch, bool synchronizing,
- bool host_writable, u64 *new_spte)
+ unsigned int host_access, u64 *new_spte)
{
int level = sp->role.level;
u64 spte = SPTE_MMU_PRESENT_MASK;
@@ -207,6 +207,11 @@ bool make_spte(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp,
if (!prefetch || synchronizing)
spte |= shadow_accessed_mask;
+ if (host_access & ACC_WRITE_MASK)
+ spte |= shadow_host_writable_mask;
+
+ pte_access &= host_access;
+
/*
* For simplicity, enforce the NX huge page mitigation even if not
* strictly necessary. KVM could ignore the mitigation if paging is
@@ -246,11 +251,6 @@ bool make_spte(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp,
if (kvm_x86_ops.get_mt_mask)
spte |= kvm_x86_call(get_mt_mask)(vcpu, gfn,
kvm_is_mmio_pfn(pfn, &is_host_mmio));
- if (host_writable)
- spte |= shadow_host_writable_mask;
- else
- pte_access &= ~ACC_WRITE_MASK;
-
if (shadow_me_value && !kvm_is_mmio_pfn(pfn, &is_host_mmio))
spte |= shadow_me_value;
diff --git a/arch/x86/kvm/mmu/spte.h b/arch/x86/kvm/mmu/spte.h
index e730717824b3..589f3954633e 100644
--- a/arch/x86/kvm/mmu/spte.h
+++ b/arch/x86/kvm/mmu/spte.h
@@ -563,7 +563,7 @@ bool make_spte(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp,
const struct kvm_memory_slot *slot,
unsigned int pte_access, gfn_t gfn, kvm_pfn_t pfn,
u64 old_spte, bool prefetch, bool synchronizing,
- bool host_writable, u64 *new_spte);
+ unsigned int host_access, u64 *new_spte);
u64 make_small_spte(struct kvm *kvm, u64 huge_spte,
union kvm_mmu_page_role role, int index);
u64 make_huge_spte(struct kvm *kvm, u64 small_spte, int level);
diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
index 44dad106fad1..dce44b9ce73a 100644
--- a/arch/x86/kvm/mmu/tdp_mmu.c
+++ b/arch/x86/kvm/mmu/tdp_mmu.c
@@ -1143,7 +1143,7 @@ static int tdp_mmu_map_handle_target_level(struct kvm_vcpu *vcpu,
else
wrprot = make_spte(vcpu, sp, fault->slot, sp->role.access, iter->gfn,
fault->pfn, iter->old_spte, fault->prefetch,
- false, fault->map_writable, &new_spte);
+ false, fault->host_access, &new_spte);
if (new_spte == iter->old_spte)
ret = RET_PF_SPURIOUS;
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v2 09/28] KVM: x86/mmu: Init memslot hugepage information for non-private_mem VMs too
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
` (7 preceding siblings ...)
2026-09-18 8:15 ` [PATCH v2 08/28] KVM: x86/mmu: Extend map_writable to a full ACC_* mask Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:15 ` [PATCH v2 10/28] KVM: pass kvm == NULL case to kvm_arch_has_private_mem Paolo Bonzini
` (18 subsequent siblings)
27 siblings, 0 replies; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
From: Nicolas Saenz Julienne <nsaenz@amazon.com>
The list of supported memory attributes is about to grow, and they will
be available on any VM type (as opposed to only ones targeted at
confidential computing). As such, update the check in
kvm_mmu_init_memslot_memory_attributes() to initialize huge page
information if any kind of memory attributes is available for the VM.
Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/kvm/mmu/mmu.c | 2 +-
include/linux/kvm_host.h | 5 +++++
virt/kvm/kvm_main.c | 2 +-
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index b72ccbee0d86..ba462c671f7d 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -8275,7 +8275,7 @@ void kvm_mmu_init_memslot_memory_attributes(struct kvm *kvm,
{
int level;
- if (!kvm_arch_has_private_mem(kvm))
+ if (!kvm_supported_mem_attributes(kvm))
return;
for (level = PG_LEVEL_2M; level <= KVM_MAX_HUGEPAGE_LEVEL; level++) {
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index ce5757e85ae3..acffb2f79b3e 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -2579,12 +2579,17 @@ bool kvm_arch_pre_set_memory_attributes(struct kvm *kvm,
struct kvm_gfn_range *range);
bool kvm_arch_post_set_memory_attributes(struct kvm *kvm,
struct kvm_gfn_range *range);
+u64 kvm_supported_mem_attributes(struct kvm *kvm);
static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn)
{
return kvm_get_memory_attributes(kvm, gfn) & KVM_MEMORY_ATTRIBUTE_PRIVATE;
}
#else
+static inline u64 kvm_supported_mem_attributes(struct kvm *kvm)
+{
+ return 0;
+}
static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn)
{
return false;
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 65eb26a0520d..3d574e16de45 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2420,7 +2420,7 @@ static int kvm_vm_ioctl_clear_dirty_log(struct kvm *kvm,
#endif /* CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT */
#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
-static u64 kvm_supported_mem_attributes(struct kvm *kvm)
+u64 kvm_supported_mem_attributes(struct kvm *kvm)
{
if (!kvm || kvm_arch_has_private_mem(kvm))
return KVM_MEMORY_ATTRIBUTE_PRIVATE;
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v2 10/28] KVM: pass kvm == NULL case to kvm_arch_has_private_mem
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
` (8 preceding siblings ...)
2026-09-18 8:15 ` [PATCH v2 09/28] KVM: x86/mmu: Init memslot hugepage information for non-private_mem VMs too Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:15 ` [PATCH v2 11/28] KVM: adjust for presence of more than one attribute Paolo Bonzini
` (17 subsequent siblings)
27 siblings, 0 replies; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
Allow the architecture-specific code to enable
CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES without exposing
KVM_MEMORY_ATTRIBUTE_PRIVATE. This is mostly for consistency after
introducing memory protection attributes; non-x86 architectures
might want to add support for protection attributes without having
KVM_MEMORY_ATTRIBUTE_PRIVATE show up in KVM_CHECK_EXTENSION.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/include/asm/kvm_host.h | 2 +-
virt/kvm/kvm_main.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index c08781bb0327..c619552740a8 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1853,7 +1853,7 @@ enum kvm_intr_type {
(!!in_nmi() == ((vcpu)->arch.handling_intr_from_guest == KVM_HANDLING_NMI)))
#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
-#define kvm_arch_has_private_mem(kvm) ((kvm)->arch.has_private_mem)
+#define kvm_arch_has_private_mem(kvm) (!(kvm) || (kvm)->arch.has_private_mem)
#endif
#define kvm_arch_has_readonly_mem(kvm) (!(kvm)->arch.has_protected_state)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 3d574e16de45..9d1836382d19 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2422,7 +2422,7 @@ static int kvm_vm_ioctl_clear_dirty_log(struct kvm *kvm,
#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
u64 kvm_supported_mem_attributes(struct kvm *kvm)
{
- if (!kvm || kvm_arch_has_private_mem(kvm))
+ if (kvm_arch_has_private_mem(kvm))
return KVM_MEMORY_ATTRIBUTE_PRIVATE;
return 0;
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v2 11/28] KVM: adjust for presence of more than one attribute
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
` (9 preceding siblings ...)
2026-09-18 8:15 ` [PATCH v2 10/28] KVM: pass kvm == NULL case to kvm_arch_has_private_mem Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:15 ` [PATCH v2 12/28] KVM: Introduce NR/NW/NX memory attributes Paolo Bonzini
` (16 subsequent siblings)
27 siblings, 0 replies; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
Remove or adjust code that assumed that the only valid attribute was
KVM_MEMORY_ATTRIBUTE_PRIVATE, in preparation for the introduction of RWX
memory attributes.
In particular, the optimization in kvm_range_has_memory_attributes
simply is not valid if attrs == 0 but some of the attributes are being
ignored. The WARNs in arch/x86/kvm/mmu/mmu.c are just a duplicate of
checking kvm_supported_mem_attributes() during the ioctl, so drop it.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/kvm/mmu/mmu.c | 9 +--------
virt/kvm/kvm_main.c | 6 ++++--
2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index ba462c671f7d..77d9c62d2a07 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -8140,9 +8140,6 @@ bool kvm_arch_pre_set_memory_attributes(struct kvm *kvm,
* Zapping SPTEs in this case ensures KVM will reassess whether or not
* a hugepage can be used for affected ranges.
*/
- if (WARN_ON_ONCE(!kvm_arch_has_private_mem(kvm)))
- return false;
-
if (WARN_ON_ONCE(range->end <= range->start))
return false;
@@ -8218,11 +8215,7 @@ bool kvm_arch_post_set_memory_attributes(struct kvm *kvm,
* can't map memory PRIVATE. KVM mustn't create a SHARED hugepage over
* a range that has PRIVATE GFNs, and conversely converting a range to
* SHARED may now allow hugepages.
- */
- if (WARN_ON_ONCE(!kvm_arch_has_private_mem(kvm)))
- return false;
-
- /*
+ *
* The sequence matters here: upper levels consume the result of lower
* level's scanning.
*/
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 9d1836382d19..85fdd33c51ab 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2436,10 +2436,12 @@ bool kvm_range_has_memory_attributes(struct kvm *kvm, gfn_t start, gfn_t end,
unsigned long mask, unsigned long attrs)
{
XA_STATE(xas, &kvm->mem_attr_array, start);
+ unsigned long supported_attrs;
unsigned long index;
void *entry;
- mask &= kvm_supported_mem_attributes(kvm);
+ supported_attrs = kvm_supported_mem_attributes(kvm);
+ mask &= supported_attrs;
if (attrs & ~mask)
return false;
@@ -2447,7 +2449,7 @@ bool kvm_range_has_memory_attributes(struct kvm *kvm, gfn_t start, gfn_t end,
return (kvm_get_memory_attributes(kvm, start) & mask) == attrs;
guard(rcu)();
- if (!attrs)
+ if (!attrs && mask == supported_attrs)
return !xas_find(&xas, end - 1);
for (index = start; index < end; index++) {
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v2 12/28] KVM: Introduce NR/NW/NX memory attributes
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
` (10 preceding siblings ...)
2026-09-18 8:15 ` [PATCH v2 11/28] KVM: adjust for presence of more than one attribute Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:36 ` sashiko-bot
2026-09-18 8:15 ` [PATCH v2 13/28] KVM: Include memory protections in result of gfn->hva conversion Paolo Bonzini
` (15 subsequent siblings)
27 siblings, 1 reply; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
From: Nicolas Saenz Julienne <nsaenz@amazon.com>
Introduce memory attributes to map guest physical memory regions as
non-readable, non-writable, and/or non-executable. Only a subset of flag
combinations is supported. Notably write and exec permissions require
read permission, and memory protection attributes are incompatible with
private memory.
As mentioned in 5a475554db1e ("KVM: Introduce per-page memory attributes",
2023-11-13), bits 0-2 of the memory attributes were reserved for RWX
protection; they are negated to support current memory attribute users
which use 0 to indicate no special treatment. Since 0 is not available,
a non-negated version of the flags would need an extra bit to express
no-access (R=0/W=0/X=0) mappings.
Unfortunately this precaution did not age too well; KVM now supports
MBEC/GMET and adding mode-based memory protections will require a
non-contiguous bit. But that's something left for later.
Different architectures may have different limitations on the set of
valid protections, for example execution-only and XU=0 mappings are
supported by Intel but not AMD processors[1]. So, add an architecture-specific
callback and add a basic implementation for x86.
[1] When adding support for MBEC/GMET, since NX would remain to mean no
execution at all, it is possible to use either an NXS bit or two
separate NXS/NXU bits in addition to NX. The former would only
support permissions that are available with either MBEC or GMET.
Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
Documentation/virt/kvm/api.rst | 14 +++++++---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/Kconfig | 4 +--
arch/x86/kvm/mmu/mmu.c | 47 +++++++++++++++++++++++++--------
arch/x86/kvm/x86.c | 2 --
include/linux/kvm_host.h | 28 +++++++++++++++++++-
include/uapi/linux/kvm.h | 3 +++
virt/kvm/kvm_main.c | 32 +++++++++++++++++++---
8 files changed, 107 insertions(+), 24 deletions(-)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index abc2ff1f8c84..81126ac11bf8 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -6414,15 +6414,23 @@ of guest physical memory.
__u64 flags;
};
+ #define KVM_MEMORY_ATTRIBUTE_NR (1ULL << 0)
+ #define KVM_MEMORY_ATTRIBUTE_NW (1ULL << 1)
+ #define KVM_MEMORY_ATTRIBUTE_NX (1ULL << 2)
#define KVM_MEMORY_ATTRIBUTE_PRIVATE (1ULL << 3)
The address and size must be page aligned. The supported attributes can be
retrieved via ioctl(KVM_CHECK_EXTENSION) on KVM_CAP_MEMORY_ATTRIBUTES. If
executed on a VM, KVM_CAP_MEMORY_ATTRIBUTES precisely returns the attributes
supported by that VM. If executed at system scope, KVM_CAP_MEMORY_ATTRIBUTES
-returns all attributes supported by KVM. The only attribute defined at this
-time is KVM_MEMORY_ATTRIBUTE_PRIVATE, which marks the associated gfn as being
-guest private memory.
+returns all attributes supported by KVM. The attribute defined at this
+time are:
+
+ - KVM_MEMORY_ATTRIBUTE_NR/NW/NX - Respectively marks the memory region as
+ non-read, non-write and/or non-exec. Note that write-only, exec-only and
+ write-exec mappings are not supported.
+ - KVM_MEMORY_ATTRIBUTE_PRIVATE - Which marks the associated gfn as being guest
+ private memory.
Note, there is no "get" API. Userspace is responsible for explicitly tracking
the state of a gfn/page as needed.
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index c619552740a8..52c432f9bc66 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1853,6 +1853,7 @@ enum kvm_intr_type {
(!!in_nmi() == ((vcpu)->arch.handling_intr_from_guest == KVM_HANDLING_NMI)))
#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
+#define kvm_arch_has_memory_protection_attributes(kvm) (!(kvm) || !(kvm)->arch.has_private_mem)
#define kvm_arch_has_private_mem(kvm) (!(kvm) || (kvm)->arch.has_private_mem)
#endif
diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
index 538ed1e80332..4c630fd64fd2 100644
--- a/arch/x86/kvm/Kconfig
+++ b/arch/x86/kvm/Kconfig
@@ -48,6 +48,7 @@ config KVM_X86
select KVM_GENERIC_PRE_FAULT_MEMORY
select KVM_WERROR if WERROR
select KVM_GUEST_MEMFD if X86_64
+ select KVM_GENERIC_MEMORY_ATTRIBUTES
config KVM
tristate "Kernel-based Virtual Machine (KVM) support"
@@ -84,7 +85,6 @@ config KVM_SW_PROTECTED_VM
bool "Enable support for KVM software-protected VMs"
depends on EXPERT
depends on KVM_X86 && X86_64
- select KVM_GENERIC_MEMORY_ATTRIBUTES
help
Enable support for KVM software-protected VMs. Currently, software-
protected VMs are purely a development and testing vehicle for
@@ -135,7 +135,6 @@ config KVM_INTEL_TDX
bool "Intel Trust Domain Extensions (TDX) support"
default y
depends on INTEL_TDX_HOST
- select KVM_GENERIC_MEMORY_ATTRIBUTES
select HAVE_KVM_ARCH_GMEM_POPULATE
help
Provides support for launching Intel Trust Domain Extensions (TDX)
@@ -159,7 +158,6 @@ config KVM_AMD_SEV
depends on KVM_AMD && X86_64
depends on CRYPTO_DEV_SP_PSP && !(KVM_AMD=y && CRYPTO_DEV_CCP_DD=m)
select ARCH_HAS_CC_PLATFORM
- select KVM_GENERIC_MEMORY_ATTRIBUTES
select HAVE_KVM_ARCH_GMEM_CONVERT
select HAVE_KVM_ARCH_GMEM_RECLAIM
select HAVE_KVM_ARCH_GMEM_INVALIDATE
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 77d9c62d2a07..797b18201d98 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -8104,7 +8104,6 @@ void kvm_mmu_pre_destroy_vm(struct kvm *kvm)
vhost_task_stop(kvm->arch.nx_huge_page_recovery_thread);
}
-#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
static bool hugepage_test_mixed(struct kvm_memory_slot *slot, gfn_t gfn,
int level)
{
@@ -8130,16 +8129,23 @@ bool kvm_arch_pre_set_memory_attributes(struct kvm *kvm,
int level;
/*
- * Zap SPTEs even if the slot can't be mapped PRIVATE. KVM x86 only
- * supports KVM_MEMORY_ATTRIBUTE_PRIVATE, and so it *seems* like KVM
- * can simply ignore such slots. But if userspace is making memory
- * PRIVATE, then KVM must prevent the guest from accessing the memory
- * as shared. And if userspace is making memory SHARED and this point
- * is reached, then at least one page within the range was previously
- * PRIVATE, i.e. the slot's possible hugepage ranges are changing.
- * Zapping SPTEs in this case ensures KVM will reassess whether or not
- * a hugepage can be used for affected ranges.
+ * For KVM_MEMORY_ATTRIBUTE_PRIVATE:
+ * Zap SPTEs even if the slot can't be mapped PRIVATE. KVM x86 only
+ * supports KVM_MEMORY_ATTRIBUTE_PRIVATE, and so it *seems* like KVM
+ * can simply ignore such slots. But if userspace is making memory
+ * PRIVATE, then KVM must prevent the guest from accessing the memory
+ * as shared. And if userspace is making memory SHARED and this point
+ * is reached, then at least one page within the range was previously
+ * PRIVATE, i.e. the slot's possible hugepage ranges are changing.
+ * Zapping SPTEs in this case ensures KVM will reassess whether or not
+ * a hugepage can be used for affected ranges.
+ *
+ * For KVM_MEMORY_ATTRIBUTE_NR/NW/NX:
+ * Zap even when loosening restrictions R=>RW, which is nost strictly
+ * necessary, but will allow KVM to reasses whether a hugepage can be
+ * used for the affected pages.
*/
+
if (WARN_ON_ONCE(range->end <= range->start))
return false;
@@ -8299,4 +8305,23 @@ void kvm_mmu_init_memslot_memory_attributes(struct kvm *kvm,
}
}
}
-#endif
+
+/* The bits are flipped but remain in the same position. */
+#define KVM_PROT_READ KVM_MEMORY_ATTRIBUTE_NR
+#define KVM_PROT_WRITE KVM_MEMORY_ATTRIBUTE_NW
+#define KVM_PROT_EXEC KVM_MEMORY_ATTRIBUTE_NX
+
+bool kvm_arch_mem_attributes_supported_prot(struct kvm *kvm, unsigned long attrs)
+{
+ unsigned long prot = (attrs & KVM_MEMORY_ATTRIBUTE_PROT) ^ KVM_MEMORY_ATTRIBUTE_PROT;
+
+ /* Private memory and access permissions are incompatible */
+ if (attrs & KVM_MEMORY_ATTRIBUTE_PRIVATE)
+ return false;
+
+ /* For now do now support exec-only, even though EPT can handle it. */
+ if (prot && !(prot & KVM_PROT_READ))
+ return false;
+
+ return true;
+}
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c10b3fd48b65..416b2ebf1c70 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -10163,9 +10163,7 @@ static int kvm_alloc_memslot_metadata(struct kvm *kvm,
}
}
-#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
kvm_mmu_init_memslot_memory_attributes(kvm, slot);
-#endif
if (kvm_page_track_create_memslot(kvm, slot, npages))
goto out_free;
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index acffb2f79b3e..c215e3bdf043 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -722,7 +722,9 @@ static inline int kvm_arch_vcpu_memslots_id(struct kvm_vcpu *vcpu)
}
#endif
-#ifndef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
+#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
+bool kvm_arch_mem_attributes_supported_prot(struct kvm *kvm, unsigned long attrs);
+#else
static inline bool kvm_arch_has_private_mem(struct kvm *kvm)
{
return false;
@@ -2567,7 +2569,25 @@ static inline bool kvm_memslot_is_gmem_only(const struct kvm_memory_slot *slot)
return slot->flags & KVM_MEMSLOT_GMEM_ONLY;
}
+static inline bool kvm_mem_attributes_may_read(u64 attrs)
+{
+ return !(attrs & KVM_MEMORY_ATTRIBUTE_NR);
+}
+
+static inline bool kvm_mem_attributes_may_write(u64 attrs)
+{
+ return !(attrs & KVM_MEMORY_ATTRIBUTE_NW);
+}
+
+static inline bool kvm_mem_attributes_may_exec(u64 attrs)
+{
+ return !(attrs & KVM_MEMORY_ATTRIBUTE_NX);
+}
+
#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
+#define KVM_MEMORY_ATTRIBUTE_PROT \
+ (KVM_MEMORY_ATTRIBUTE_NR | KVM_MEMORY_ATTRIBUTE_NW | KVM_MEMORY_ATTRIBUTE_NX)
+
static inline unsigned long kvm_get_memory_attributes(struct kvm *kvm, gfn_t gfn)
{
return xa_to_value(xa_load(&kvm->mem_attr_array, gfn));
@@ -2579,6 +2599,7 @@ bool kvm_arch_pre_set_memory_attributes(struct kvm *kvm,
struct kvm_gfn_range *range);
bool kvm_arch_post_set_memory_attributes(struct kvm *kvm,
struct kvm_gfn_range *range);
+bool kvm_mem_attributes_valid(struct kvm *kvm, unsigned long attrs);
u64 kvm_supported_mem_attributes(struct kvm *kvm);
static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn)
@@ -2586,6 +2607,11 @@ static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn)
return kvm_get_memory_attributes(kvm, gfn) & KVM_MEMORY_ATTRIBUTE_PRIVATE;
}
#else
+static inline bool kvm_mem_attributes_valid(struct kvm *kvm,
+ unsigned long attrs)
+{
+ return false;
+}
static inline u64 kvm_supported_mem_attributes(struct kvm *kvm)
{
return 0;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index c23f1ea62eaf..ffbc68a6e2c9 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1657,6 +1657,9 @@ struct kvm_memory_attributes {
__u64 flags;
};
+#define KVM_MEMORY_ATTRIBUTE_NR (1ULL << 0)
+#define KVM_MEMORY_ATTRIBUTE_NW (1ULL << 1)
+#define KVM_MEMORY_ATTRIBUTE_NX (1ULL << 2)
#define KVM_MEMORY_ATTRIBUTE_PRIVATE (1ULL << 3)
#define KVM_CREATE_GUEST_MEMFD _IOWR(KVMIO, 0xd4, struct kvm_create_guest_memfd)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 85fdd33c51ab..f98104169862 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2422,10 +2422,15 @@ static int kvm_vm_ioctl_clear_dirty_log(struct kvm *kvm,
#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
u64 kvm_supported_mem_attributes(struct kvm *kvm)
{
- if (kvm_arch_has_private_mem(kvm))
- return KVM_MEMORY_ATTRIBUTE_PRIVATE;
+ u64 supported_attrs = 0;
- return 0;
+ if (kvm_arch_has_memory_protection_attributes(kvm))
+ supported_attrs |= KVM_MEMORY_ATTRIBUTE_PROT;
+
+ if (kvm_arch_has_private_mem(kvm))
+ supported_attrs |= KVM_MEMORY_ATTRIBUTE_PRIVATE;
+
+ return supported_attrs;
}
/*
@@ -2599,6 +2604,25 @@ static int kvm_vm_set_mem_attributes(struct kvm *kvm, gfn_t start, gfn_t end,
return r;
}
+
+bool __weak kvm_arch_mem_attributes_supported_prot(struct kvm *kvm, unsigned long attrs)
+{
+ WARN_ON_ONCE("KVM_MEMORY_ATTRIBUTE_PROT requires kvm_arch_mem_attributes_supported_prot()");
+ return false;
+}
+
+bool kvm_mem_attributes_valid(struct kvm *kvm, unsigned long attrs)
+{
+ if (attrs & ~kvm_supported_mem_attributes(kvm))
+ return false;
+
+ if ((attrs & KVM_MEMORY_ATTRIBUTE_PROT) &&
+ !kvm_arch_mem_attributes_supported_prot(kvm, attrs))
+ return false;
+
+ return true;
+}
+
static int kvm_vm_ioctl_set_mem_attributes(struct kvm *kvm,
struct kvm_memory_attributes *attrs)
{
@@ -2607,7 +2631,7 @@ static int kvm_vm_ioctl_set_mem_attributes(struct kvm *kvm,
/* flags is currently not used. */
if (attrs->flags)
return -EINVAL;
- if (attrs->attributes & ~kvm_supported_mem_attributes(kvm))
+ if (!kvm_mem_attributes_valid(kvm, attrs->attributes))
return -EINVAL;
if (attrs->size == 0 || attrs->address + attrs->size < attrs->address)
return -EINVAL;
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* Re: [PATCH v2 12/28] KVM: Introduce NR/NW/NX memory attributes
2026-09-18 8:15 ` [PATCH v2 12/28] KVM: Introduce NR/NW/NX memory attributes Paolo Bonzini
@ 2026-09-18 8:36 ` sashiko-bot
0 siblings, 0 replies; 44+ messages in thread
From: sashiko-bot @ 2026-09-18 8:36 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: kvm
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] kvm: API Misuse in WARN_ON_ONCE with string literal
--
commit e4ff873cd187bd01c3fc362fdaed04c8d470baa7
Author: Nicolas Saenz Julienne <nsaenz@amazon.com>
KVM: Introduce NR/NW/NX memory attributes
This commit introduces memory attributes to map guest physical memory
regions as non-readable, non-writable, and/or non-executable. It also
adds an architecture-specific callback and a basic implementation for x86.
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 50e042c58246f..452ec3a99ba6f 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
[ ... ]
> +
> +bool __weak kvm_arch_mem_attributes_supported_prot(struct kvm *kvm, unsigned long attrs)
> +{
> + WARN_ON_ONCE("KVM_MEMORY_ATTRIBUTE_PROT requires kvm_arch_mem_attributes_supported_prot()");
[Severity: Low]
Does this code use the WARN_ON_ONCE macro correctly? Passing a string
literal as the condition evaluates to a non-NULL pointer, which is always
true.
When an architecture implements memory protection attributes without
overriding kvm_arch_mem_attributes_supported_prot(), the weak fallback
triggers this warning unconditionally. It will also fail to format or print
the intended string as a log message, producing a stack trace without the
descriptive message.
Should this perhaps use WARN_ONCE instead to print the descriptive warning,
or pass a proper boolean condition to WARN_ON_ONCE?
> + return false;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918081543.139871-1-pbonzini@redhat.com?part=12
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v2 13/28] KVM: Include memory protections in result of gfn->hva conversion
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
` (11 preceding siblings ...)
2026-09-18 8:15 ` [PATCH v2 12/28] KVM: Introduce NR/NW/NX memory attributes Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:15 ` [PATCH v2 14/28] KVM: Introduce kvm_fetch_guest_page() and use it for x86 Paolo Bonzini
` (14 subsequent siblings)
27 siblings, 0 replies; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
From: Nicolas Saenz Julienne <nsaenz@amazon.com>
All paths that lead to guest memory accesses now need to check whether
memory attributes allow that access. Users of gfn_to_hva,
kvm_vcpu_gfn_to_hva and their *_prot variant can get it more or
less for free via erroneous return values, so do this first.
Note however that this is not true of the variants that take a cached
kvm_memslots pointer. These include caches (gfn-to-hva and gfn-to-pfn)
and page faults, both of which will need specific changes; but the more
optimized functions in virt/kvm/kvm_main.c such as kvm_read_guest()
and kvm_write_guest() also retrieve the memslot high in the call chain,
and therefore they will need changes in __kvm_read/write_guest_page().
Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
include/linux/kvm_host.h | 18 +++++++++++++
virt/kvm/kvm_main.c | 55 +++++++++++++++++++++++++++++++++++++---
2 files changed, 69 insertions(+), 4 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index c215e3bdf043..01223301f0e5 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -2620,8 +2620,26 @@ static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn)
{
return false;
}
+static inline unsigned long kvm_get_memory_attributes(struct kvm *kvm, gfn_t gfn)
+{
+ return 0;
+}
#endif /* CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES */
+static inline int kvm_mem_attributes_may_read_gfn(struct kvm *kvm, gfn_t gfn)
+{
+ unsigned long attrs = kvm_get_memory_attributes(kvm, gfn);
+
+ return kvm_mem_attributes_may_read(attrs);
+}
+
+static inline int kvm_mem_attributes_may_write_gfn(struct kvm *kvm, gfn_t gfn)
+{
+ unsigned long attrs = kvm_get_memory_attributes(kvm, gfn);
+
+ return kvm_mem_attributes_may_write(attrs);
+}
+
#ifdef CONFIG_KVM_GUEST_MEMFD
int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory_slot *slot,
gfn_t gfn, kvm_pfn_t *pfn, struct page **page,
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index f98104169862..b1cc570be8df 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2767,13 +2767,38 @@ EXPORT_SYMBOL_FOR_KVM_INTERNAL(gfn_to_hva_memslot);
unsigned long gfn_to_hva(struct kvm *kvm, gfn_t gfn)
{
- return gfn_to_hva_many(gfn_to_memslot(kvm, gfn), gfn, NULL);
+ unsigned long addr;
+
+ addr = gfn_to_hva_many(gfn_to_memslot(kvm, gfn), gfn, NULL);
+ if (kvm_is_error_hva(addr))
+ return addr;
+
+ if (!kvm_mem_attributes_may_read_gfn(kvm, gfn))
+ return KVM_HVA_ERR_BAD;
+
+ if (!kvm_mem_attributes_may_write_gfn(kvm, gfn))
+ return KVM_HVA_ERR_RO_BAD;
+
+ return addr;
}
EXPORT_SYMBOL_FOR_KVM_INTERNAL(gfn_to_hva);
unsigned long kvm_vcpu_gfn_to_hva(struct kvm_vcpu *vcpu, gfn_t gfn)
{
- return gfn_to_hva_many(kvm_vcpu_gfn_to_memslot(vcpu, gfn), gfn, NULL);
+ struct kvm *kvm = vcpu->kvm;
+ unsigned long addr;
+
+ addr = gfn_to_hva_many(kvm_vcpu_gfn_to_memslot(vcpu, gfn), gfn, NULL);
+ if (kvm_is_error_hva(addr))
+ return addr;
+
+ if (!kvm_mem_attributes_may_read_gfn(kvm, gfn))
+ return KVM_HVA_ERR_BAD;
+
+ if (!kvm_mem_attributes_may_write_gfn(kvm, gfn))
+ return KVM_HVA_ERR_RO_BAD;
+
+ return addr;
}
EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_vcpu_gfn_to_hva);
@@ -2799,15 +2824,37 @@ unsigned long gfn_to_hva_memslot_prot(struct kvm_memory_slot *slot,
unsigned long gfn_to_hva_prot(struct kvm *kvm, gfn_t gfn, bool *writable)
{
struct kvm_memory_slot *slot = gfn_to_memslot(kvm, gfn);
+ unsigned long addr;
- return gfn_to_hva_memslot_prot(slot, gfn, writable);
+ addr = gfn_to_hva_memslot_prot(slot, gfn, writable);
+ if (kvm_is_error_hva(addr))
+ return addr;
+
+ if (!kvm_mem_attributes_may_read_gfn(kvm, gfn))
+ return KVM_HVA_ERR_BAD;
+
+ if (writable && !kvm_mem_attributes_may_write_gfn(kvm, gfn))
+ *writable = false;
+
+ return addr;
}
unsigned long kvm_vcpu_gfn_to_hva_prot(struct kvm_vcpu *vcpu, gfn_t gfn, bool *writable)
{
struct kvm_memory_slot *slot = kvm_vcpu_gfn_to_memslot(vcpu, gfn);
+ unsigned long addr;
- return gfn_to_hva_memslot_prot(slot, gfn, writable);
+ addr = gfn_to_hva_memslot_prot(slot, gfn, writable);
+ if (kvm_is_error_hva(addr))
+ return addr;
+
+ if (!kvm_mem_attributes_may_read_gfn(vcpu->kvm, gfn))
+ return KVM_HVA_ERR_BAD;
+
+ if (writable && !kvm_mem_attributes_may_write_gfn(vcpu->kvm, gfn))
+ *writable = false;
+
+ return addr;
}
static bool kvm_is_ad_tracked_page(struct page *page)
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v2 14/28] KVM: Introduce kvm_fetch_guest_page() and use it for x86
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
` (12 preceding siblings ...)
2026-09-18 8:15 ` [PATCH v2 13/28] KVM: Include memory protections in result of gfn->hva conversion Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:15 ` [PATCH v2 15/28] KVM: Take memory protections into account for memory read/write/fetch Paolo Bonzini
` (13 subsequent siblings)
27 siblings, 0 replies; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
Introduce a separate function so that the emulator will be able to take
into account execution memory attributes rather than read.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/kvm/x86.c | 4 ++--
include/linux/kvm_host.h | 2 ++
virt/kvm/kvm_main.c | 9 +++++++++
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 416b2ebf1c70..6c0c95b92b5a 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4872,8 +4872,8 @@ static int kvm_fetch_guest_virt(struct x86_emulate_ctxt *ctxt,
offset = addr & (PAGE_SIZE-1);
if (WARN_ON(offset + bytes > PAGE_SIZE))
bytes = (unsigned)PAGE_SIZE - offset;
- ret = kvm_vcpu_read_guest_page(vcpu, gpa >> PAGE_SHIFT, val,
- offset, bytes);
+ ret = kvm_vcpu_fetch_guest_page(vcpu, gpa >> PAGE_SHIFT, val,
+ offset, bytes);
if (unlikely(ret < 0))
return X86EMUL_IO_NEEDED;
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 01223301f0e5..cddf0b943757 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -1444,6 +1444,8 @@ DEFINE_VCPU_MAP_CLASS(_readonly);
unsigned long kvm_vcpu_gfn_to_hva(struct kvm_vcpu *vcpu, gfn_t gfn);
unsigned long kvm_vcpu_gfn_to_hva_prot(struct kvm_vcpu *vcpu, gfn_t gfn, bool *writable);
+int kvm_vcpu_fetch_guest_page(struct kvm_vcpu *vcpu, gfn_t gfn, void *data,
+ int offset, int len);
int kvm_vcpu_read_guest_page(struct kvm_vcpu *vcpu, gfn_t gfn, void *data, int offset,
int len);
int kvm_vcpu_read_guest_atomic(struct kvm_vcpu *vcpu, gpa_t gpa, void *data,
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index b1cc570be8df..7cb7ff202fc0 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3291,6 +3291,15 @@ int kvm_vcpu_read_guest_page(struct kvm_vcpu *vcpu, gfn_t gfn, void *data,
}
EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_vcpu_read_guest_page);
+int kvm_vcpu_fetch_guest_page(struct kvm_vcpu *vcpu, gfn_t gfn, void *data,
+ int offset, int len)
+{
+ struct kvm_memory_slot *slot = kvm_vcpu_gfn_to_memslot(vcpu, gfn);
+
+ return __kvm_read_guest_page(vcpu->kvm, slot, gfn, data, offset, len);
+}
+EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_vcpu_fetch_guest_page);
+
int kvm_read_guest(struct kvm *kvm, gpa_t gpa, void *data, unsigned long len)
{
gfn_t gfn = gpa >> PAGE_SHIFT;
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v2 15/28] KVM: Take memory protections into account for memory read/write/fetch
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
` (13 preceding siblings ...)
2026-09-18 8:15 ` [PATCH v2 14/28] KVM: Introduce kvm_fetch_guest_page() and use it for x86 Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:34 ` sashiko-bot
2026-09-18 8:15 ` [PATCH v2 16/28] KVM: Encapsulate memattrs array into anonymous struct Paolo Bonzini
` (12 subsequent siblings)
27 siblings, 1 reply; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
From: Nicolas Saenz Julienne <nsaenz@amazon.com>
Take into account memory attributes when accessing guest memory through
the kvm_{read,write,fetch}*() family of functions.
All of these pass a struct kvm_memory_slot pointer to the actual
workhorse functions, in order to share code between the VM-wide and
vCPU-specific version of the functions (the latter of which handles the
multi-address-space case). For this reason they need specific changes
and do not work even though the gfn_to_hva() path has been taught already
about memory protection attributes.
Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
virt/kvm/kvm_main.c | 34 ++++++++++++++++++++++++++--------
1 file changed, 26 insertions(+), 8 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 7cb7ff202fc0..3932e526870a 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3255,11 +3255,13 @@ static int next_segment(unsigned long len, int offset)
}
/* Copy @len bytes from guest memory at '(@gfn * PAGE_SIZE) + @offset' to @data */
-static int __kvm_read_guest_page(struct kvm_memory_slot *slot, gfn_t gfn,
- void *data, int offset, int len)
+static int __kvm_read_guest_page(struct kvm *kvm, struct kvm_memory_slot *slot,
+ gfn_t gfn, void *data, int offset, int len,
+ unsigned long attr)
{
int r;
unsigned long addr;
+ unsigned long attrs;
if (WARN_ON_ONCE(offset + len > PAGE_SIZE))
return -EFAULT;
@@ -3267,6 +3269,11 @@ static int __kvm_read_guest_page(struct kvm_memory_slot *slot, gfn_t gfn,
addr = gfn_to_hva_memslot_prot(slot, gfn, NULL);
if (kvm_is_error_hva(addr))
return -EFAULT;
+
+ attrs = kvm_get_memory_attributes(kvm, gfn);
+ if (attrs & attr)
+ return -EFAULT;
+
r = __copy_from_user(data, (void __user *)addr + offset, len);
if (r)
return -EFAULT;
@@ -3278,7 +3285,8 @@ int kvm_read_guest_page(struct kvm *kvm, gfn_t gfn, void *data, int offset,
{
struct kvm_memory_slot *slot = gfn_to_memslot(kvm, gfn);
- return __kvm_read_guest_page(slot, gfn, data, offset, len);
+ return __kvm_read_guest_page(kvm, slot, gfn, data, offset, len,
+ KVM_MEMORY_ATTRIBUTE_NR);
}
EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_read_guest_page);
@@ -3287,7 +3295,8 @@ int kvm_vcpu_read_guest_page(struct kvm_vcpu *vcpu, gfn_t gfn, void *data,
{
struct kvm_memory_slot *slot = kvm_vcpu_gfn_to_memslot(vcpu, gfn);
- return __kvm_read_guest_page(slot, gfn, data, offset, len);
+ return __kvm_read_guest_page(vcpu->kvm, slot, gfn, data, offset, len,
+ KVM_MEMORY_ATTRIBUTE_NR);
}
EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_vcpu_read_guest_page);
@@ -3296,7 +3305,8 @@ int kvm_vcpu_fetch_guest_page(struct kvm_vcpu *vcpu, gfn_t gfn, void *data,
{
struct kvm_memory_slot *slot = kvm_vcpu_gfn_to_memslot(vcpu, gfn);
- return __kvm_read_guest_page(vcpu->kvm, slot, gfn, data, offset, len);
+ return __kvm_read_guest_page(vcpu->kvm, slot, gfn, data, offset, len,
+ KVM_MEMORY_ATTRIBUTE_NX);
}
EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_vcpu_fetch_guest_page);
@@ -3340,8 +3350,9 @@ int kvm_vcpu_read_guest(struct kvm_vcpu *vcpu, gpa_t gpa, void *data, unsigned l
}
EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_vcpu_read_guest);
-static int __kvm_read_guest_atomic(struct kvm_memory_slot *slot, gfn_t gfn,
- void *data, int offset, unsigned long len)
+static int __kvm_read_guest_atomic(struct kvm *kvm,
+ struct kvm_memory_slot *slot, gfn_t gfn,
+ void *data, int offset, unsigned long len)
{
int r;
unsigned long addr;
@@ -3349,6 +3360,9 @@ static int __kvm_read_guest_atomic(struct kvm_memory_slot *slot, gfn_t gfn,
if (WARN_ON_ONCE(offset + len > PAGE_SIZE))
return -EFAULT;
+ if (!kvm_mem_attributes_may_read_gfn(kvm, gfn))
+ return -EFAULT;
+
addr = gfn_to_hva_memslot_prot(slot, gfn, NULL);
if (kvm_is_error_hva(addr))
return -EFAULT;
@@ -3367,7 +3381,7 @@ int kvm_vcpu_read_guest_atomic(struct kvm_vcpu *vcpu, gpa_t gpa,
struct kvm_memory_slot *slot = kvm_vcpu_gfn_to_memslot(vcpu, gfn);
int offset = offset_in_page(gpa);
- return __kvm_read_guest_atomic(slot, gfn, data, offset, len);
+ return __kvm_read_guest_atomic(vcpu->kvm, slot, gfn, data, offset, len);
}
EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_vcpu_read_guest_atomic);
@@ -3385,6 +3399,10 @@ static int __kvm_write_guest_page(struct kvm *kvm,
addr = gfn_to_hva_memslot(memslot, gfn);
if (kvm_is_error_hva(addr))
return -EFAULT;
+
+ if (!kvm_mem_attributes_may_write_gfn(kvm, gfn))
+ return -EFAULT;
+
r = __copy_to_user((void __user *)addr + offset, data, len);
if (r)
return -EFAULT;
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* Re: [PATCH v2 15/28] KVM: Take memory protections into account for memory read/write/fetch
2026-09-18 8:15 ` [PATCH v2 15/28] KVM: Take memory protections into account for memory read/write/fetch Paolo Bonzini
@ 2026-09-18 8:34 ` sashiko-bot
0 siblings, 0 replies; 44+ messages in thread
From: sashiko-bot @ 2026-09-18 8:34 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: kvm
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] kvm: vcpu_map bypasses KVM_MEMORY_ATTRIBUTE_NR/NW protections
--
commit 79f1cf1f5a4245adbef80d2c22573dcd13309746
Author: Nicolas Saenz Julienne <nsaenz@amazon.com>
KVM: Take memory protections into account for memory read/write/fetch
Take into account memory attributes when accessing guest memory through
the kvm_{read,write,fetch}*() family of functions.
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index c910beb7a3aa5..e3ea9ceed01ea 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
[ ... ]
> @@ -3395,6 +3409,10 @@ static int __kvm_write_guest_page(struct kvm *kvm,
> addr = gfn_to_hva_memslot(memslot, gfn);
> if (kvm_is_error_hva(addr))
> return -EFAULT;
> +
> + if (!kvm_mem_attributes_may_write_gfn(kvm, gfn))
> + return -EFAULT;
> +
> r = __copy_to_user((void __user *)addr + offset, data, len);
> if (r)
> return -EFAULT;
[Severity: High]
While this patch updates the read/write/fetch helpers, does it inadvertently
leave __kvm_vcpu_map() vulnerable to bypassing memory protections?
In virt/kvm/kvm_main.c:__kvm_vcpu_map(), KVM resolves and maps the PFN into
kernel space without checking KVM_MEMORY_ATTRIBUTE_NR/NW memory attributes:
int __kvm_vcpu_map(struct kvm_vcpu *vcpu, gfn_t gfn, struct kvm_host_map *map,
bool writable)
{
...
map->pfn = kvm_follow_pfn(&kfp);
if (is_error_noslot_pfn(map->pfn))
return -EINVAL;
if (pfn_valid(map->pfn)) {
map->page = pfn_to_page(map->pfn);
map->hva = kmap(map->page);
...
}
If a malicious L1 guest provides a protected GPA (marked Non-Writable or
Non-Readable by host userspace via KVM_SET_MEMORY_ATTRIBUTES) to an interface
mapped via kvm_vcpu_map (such as a nested VMCS, VMCB, or APIC access page),
KVM will successfully read/write it outside the guest MMU. Can we check
kvm_get_memory_attributes() here before mapping to prevent KVM from acting
as a confused deputy and violating the host's memory protections?
While pfncache and cached offset accessors were explicitly fixed in follow-up
patches within this series (e.g., 'KVM: pfncache: Fail to refresh if it
contains memory protections' and 'KVM: Take memory protections into account
for accesses with cached gfn->hva'), __kvm_vcpu_map was missed.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918081543.139871-1-pbonzini@redhat.com?part=15
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v2 16/28] KVM: Encapsulate memattrs array into anonymous struct
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
` (14 preceding siblings ...)
2026-09-18 8:15 ` [PATCH v2 15/28] KVM: Take memory protections into account for memory read/write/fetch Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:15 ` [PATCH v2 17/28] KVM: Introduce kvm_check_gen()/kvm_memslots_check_gen() Paolo Bonzini
` (11 subsequent siblings)
27 siblings, 0 replies; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
From: Nicolas Saenz Julienne <nsaenz@amazon.com>
The metadata surrounding memory attributes is about to grow, so
encapsulate the memory attributes array within an anonymous struct to
provide namespacing.
Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
include/linux/kvm_host.h | 8 +++++---
virt/kvm/kvm_main.c | 10 +++++-----
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index cddf0b943757..24d04322d89e 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -875,8 +875,10 @@ struct kvm {
struct notifier_block pm_notifier;
#endif
#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
- /* Protected by slots_lock (for writes) and RCU (for reads) */
- struct xarray mem_attr_array;
+ struct {
+ /* Protected by slots_lock (for writes) and RCU (for reads) */
+ struct xarray array;
+ } mem_attrs;
#endif
char stats_id[KVM_STATS_NAME_SIZE];
};
@@ -2592,7 +2594,7 @@ static inline bool kvm_mem_attributes_may_exec(u64 attrs)
static inline unsigned long kvm_get_memory_attributes(struct kvm *kvm, gfn_t gfn)
{
- return xa_to_value(xa_load(&kvm->mem_attr_array, gfn));
+ return xa_to_value(xa_load(&kvm->mem_attrs.array, gfn));
}
bool kvm_range_has_memory_attributes(struct kvm *kvm, gfn_t start, gfn_t end,
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 3932e526870a..994a33a09448 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1117,7 +1117,7 @@ static struct kvm *kvm_create_vm(unsigned long type, const char *fdname)
rcuwait_init(&kvm->mn_memslots_update_rcuwait);
xa_init(&kvm->vcpu_array);
#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
- xa_init(&kvm->mem_attr_array);
+ xa_init(&kvm->mem_attrs.array);
#endif
INIT_LIST_HEAD(&kvm->gpc_list);
@@ -1302,7 +1302,7 @@ static void kvm_destroy_vm(struct kvm *kvm)
srcu_barrier(&kvm->srcu);
cleanup_srcu_struct(&kvm->srcu);
#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
- xa_destroy(&kvm->mem_attr_array);
+ xa_destroy(&kvm->mem_attrs.array);
#endif
kvm_arch_free_vm(kvm);
preempt_notifier_dec();
@@ -2440,7 +2440,7 @@ u64 kvm_supported_mem_attributes(struct kvm *kvm)
bool kvm_range_has_memory_attributes(struct kvm *kvm, gfn_t start, gfn_t end,
unsigned long mask, unsigned long attrs)
{
- XA_STATE(xas, &kvm->mem_attr_array, start);
+ XA_STATE(xas, &kvm->mem_attrs.array, start);
unsigned long supported_attrs;
unsigned long index;
void *entry;
@@ -2581,7 +2581,7 @@ static int kvm_vm_set_mem_attributes(struct kvm *kvm, gfn_t start, gfn_t end,
* partway through setting the new attributes.
*/
for (i = start; i < end; i++) {
- r = xa_reserve(&kvm->mem_attr_array, i, GFP_KERNEL_ACCOUNT);
+ r = xa_reserve(&kvm->mem_attrs.array, i, GFP_KERNEL_ACCOUNT);
if (r)
goto out_unlock;
@@ -2591,7 +2591,7 @@ static int kvm_vm_set_mem_attributes(struct kvm *kvm, gfn_t start, gfn_t end,
kvm_handle_gfn_range(kvm, &pre_set_range);
for (i = start; i < end; i++) {
- r = xa_err(xa_store(&kvm->mem_attr_array, i, entry,
+ r = xa_err(xa_store(&kvm->mem_attrs.array, i, entry,
GFP_KERNEL_ACCOUNT));
KVM_BUG_ON(r, kvm);
cond_resched();
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v2 17/28] KVM: Introduce kvm_check_gen()/kvm_memslots_check_gen()
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
` (15 preceding siblings ...)
2026-09-18 8:15 ` [PATCH v2 16/28] KVM: Encapsulate memattrs array into anonymous struct Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:15 ` [PATCH v2 18/28] KVM: Introduce a generation number for memory attributes Paolo Bonzini
` (10 subsequent siblings)
27 siblings, 0 replies; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
In many cases, retrieving kvm_memslots is followed by a check on
the generation of the slots. Introduce a helper function that
either does the check alone, or compounds it with returning the
struct kvm_memslots* to the caller.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/kvm/x86.c | 10 ++--------
include/linux/kvm_host.h | 13 +++++++++++++
virt/kvm/kvm_main.c | 8 ++++----
virt/kvm/pfncache.c | 10 ++++------
4 files changed, 23 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 6c0c95b92b5a..5b7ff5d9af75 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2049,7 +2049,6 @@ static void record_steal_time(struct kvm_vcpu *vcpu)
{
struct gfn_to_hva_cache *ghc = &vcpu->arch.st.cache;
struct kvm_steal_time __user *st;
- struct kvm_memslots *slots;
gpa_t gpa = vcpu->arch.st.msr_val & KVM_STEAL_VALID_BITS;
u64 steal;
u32 version;
@@ -2065,9 +2064,7 @@ static void record_steal_time(struct kvm_vcpu *vcpu)
if (WARN_ON_ONCE(current->mm != vcpu->kvm->mm))
return;
- slots = kvm_memslots(vcpu->kvm);
-
- if (unlikely(slots->generation != ghc->generation ||
+ if (unlikely(!kvm_check_gen(vcpu->kvm, ghc->generation) ||
gpa != ghc->gpa ||
kvm_is_error_hva(ghc->hva) || !ghc->memslot)) {
/* We rely on the fact that it fits in a single page. */
@@ -2617,7 +2614,6 @@ static void kvm_steal_time_set_preempted(struct kvm_vcpu *vcpu)
{
struct gfn_to_hva_cache *ghc = &vcpu->arch.st.cache;
struct kvm_steal_time __user *st;
- struct kvm_memslots *slots;
static const u8 preempted = KVM_VCPU_PREEMPTED;
gpa_t gpa = vcpu->arch.st.msr_val & KVM_STEAL_VALID_BITS;
@@ -2644,9 +2640,7 @@ static void kvm_steal_time_set_preempted(struct kvm_vcpu *vcpu)
if (unlikely(current->mm != vcpu->kvm->mm))
return;
- slots = kvm_memslots(vcpu->kvm);
-
- if (unlikely(slots->generation != ghc->generation ||
+ if (unlikely(!kvm_check_gen(vcpu->kvm, ghc->generation) ||
gpa != ghc->gpa ||
kvm_is_error_hva(ghc->hva) || !ghc->memslot))
return;
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 24d04322d89e..7599ab7ad7ef 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -2644,6 +2644,19 @@ static inline int kvm_mem_attributes_may_write_gfn(struct kvm *kvm, gfn_t gfn)
return kvm_mem_attributes_may_write(attrs);
}
+static inline bool kvm_memslots_check_gen(struct kvm *kvm, u64 slots_generation, struct kvm_memslots **p_slots)
+{
+ struct kvm_memslots *slots = *p_slots = kvm_memslots(kvm);
+ return slots->generation == slots_generation;
+}
+
+static inline bool kvm_check_gen(struct kvm *kvm, u64 slots_generation)
+{
+ struct kvm_memslots *slots;
+ return kvm_memslots_check_gen(kvm, slots_generation, &slots);
+}
+
+
#ifdef CONFIG_KVM_GUEST_MEMFD
int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory_slot *slot,
gfn_t gfn, kvm_pfn_t *pfn, struct page **page,
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 994a33a09448..89e79d3f27f0 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3523,14 +3523,14 @@ int kvm_write_guest_offset_cached(struct kvm *kvm, struct gfn_to_hva_cache *ghc,
void *data, unsigned int offset,
unsigned long len)
{
- struct kvm_memslots *slots = kvm_memslots(kvm);
+ struct kvm_memslots *slots;
int r;
gpa_t gpa = ghc->gpa + offset;
if (WARN_ON_ONCE(len + offset > ghc->len))
return -EINVAL;
- if (slots->generation != ghc->generation) {
+ if (unlikely(!kvm_memslots_check_gen(kvm, ghc->generation, &slots))) {
if (__kvm_gfn_to_hva_cache_init(slots, ghc, ghc->gpa, ghc->len))
return -EFAULT;
}
@@ -3561,14 +3561,14 @@ int kvm_read_guest_offset_cached(struct kvm *kvm, struct gfn_to_hva_cache *ghc,
void *data, unsigned int offset,
unsigned long len)
{
- struct kvm_memslots *slots = kvm_memslots(kvm);
+ struct kvm_memslots *slots;
int r;
gpa_t gpa = ghc->gpa + offset;
if (WARN_ON_ONCE(len + offset > ghc->len))
return -EINVAL;
- if (slots->generation != ghc->generation) {
+ if (unlikely(!kvm_memslots_check_gen(kvm, ghc->generation, &slots))) {
if (__kvm_gfn_to_hva_cache_init(slots, ghc, ghc->gpa, ghc->len))
return -EFAULT;
}
diff --git a/virt/kvm/pfncache.c b/virt/kvm/pfncache.c
index 728d2c1b488a..e09703d249bb 100644
--- a/virt/kvm/pfncache.c
+++ b/virt/kvm/pfncache.c
@@ -72,8 +72,6 @@ static bool kvm_gpc_is_valid_len(gpa_t gpa, unsigned long uhva,
bool kvm_gpc_check(struct gfn_to_pfn_cache *gpc, unsigned long len)
{
- struct kvm_memslots *slots = kvm_memslots(gpc->kvm);
-
if (!gpc->active)
return false;
@@ -81,7 +79,7 @@ bool kvm_gpc_check(struct gfn_to_pfn_cache *gpc, unsigned long len)
* If the page was cached from a memslot, make sure the memslots have
* not been re-configured.
*/
- if (!kvm_is_error_gpa(gpc->gpa) && gpc->generation != slots->generation)
+ if (!kvm_is_error_gpa(gpc->gpa) && !kvm_check_gen(gpc->kvm, gpc->generation))
return false;
if (kvm_is_error_hva(gpc->uhva))
@@ -290,12 +288,12 @@ static int __kvm_gpc_refresh(struct gfn_to_pfn_cache *gpc, gpa_t gpa, unsigned l
if (gpc->uhva != old_uhva)
hva_change = true;
} else {
- struct kvm_memslots *slots = kvm_memslots(gpc->kvm);
+ struct kvm_memslots *slots;
page_offset = offset_in_page(gpa);
- if (gpc->gpa != gpa || gpc->generation != slots->generation ||
- kvm_is_error_hva(gpc->uhva)) {
+ if (!kvm_memslots_check_gen(gpc->kvm, gpc->generation, &slots) ||
+ gpc->gpa != gpa || kvm_is_error_hva(gpc->uhva)) {
gfn_t gfn = gpa_to_gfn(gpa);
gpc->gpa = gpa;
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v2 18/28] KVM: Introduce a generation number for memory attributes
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
` (16 preceding siblings ...)
2026-09-18 8:15 ` [PATCH v2 17/28] KVM: Introduce kvm_check_gen()/kvm_memslots_check_gen() Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:39 ` sashiko-bot
2026-09-18 8:15 ` [PATCH v2 19/28] KVM: Take memory protections into account for accesses with cached gfn->hva Paolo Bonzini
` (9 subsequent siblings)
27 siblings, 1 reply; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
From: Nicolas Saenz Julienne <nsaenz@amazon.com>
Introduce a generation number to track memory attribute modifications.
This will allow KVM components to invalidate any assumptions they might
have about guest's physical addresses and their permissions when memory
attributes change.
Like with memory slot updates, it's mandatory for components that access
guest memory based on cached information to do so within a KVM SRCU
read-side critical section, and that they validate the generation number
before accessing memory. This, in combination with the
synchronize_srcu() call within the memory attributes ioctl handler,
ensures the following:
- A memory attribute modification operation only returns after all
users of outdated GPA data are done running.
- Any component accessing cached data after the memory attribute
modification returned will see the updated generation number.
Additionally, loads/stores of the generation number have
acquire/release semantics; which ensures all attribute writes are
visible before updating the generation, and loads from attributes happen
after having read the current generation number.
Ultimately, since synchronize_srcu_expedited() is an expensive
operation, only perform it when absolutely necessary. Do so if the
introduced memory attribute is known to require synchronization or if
the attribute being cleared contained a memory attribute that required
synchronization.
There shouldn't be any performance loss for memory attributes that
don't require synchronization (and in general for any VMM that does not
apply memory protections), because the attributes generation will always
remain unchanged.
Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/kvm/x86.c | 4 +-
include/linux/kvm_host.h | 34 ++++++++++++++--
include/linux/kvm_types.h | 6 ++-
include/trace/events/kvm.h | 14 +++++--
virt/kvm/kvm_main.c | 80 +++++++++++++++++++++++++++++++++-----
virt/kvm/pfncache.c | 13 ++++---
6 files changed, 124 insertions(+), 27 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 5b7ff5d9af75..f77b20e5d8f8 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2064,7 +2064,7 @@ static void record_steal_time(struct kvm_vcpu *vcpu)
if (WARN_ON_ONCE(current->mm != vcpu->kvm->mm))
return;
- if (unlikely(!kvm_check_gen(vcpu->kvm, ghc->generation) ||
+ if (unlikely(!kvm_check_gen(vcpu->kvm, ghc->slots_generation, ghc->attrs_generation) ||
gpa != ghc->gpa ||
kvm_is_error_hva(ghc->hva) || !ghc->memslot)) {
/* We rely on the fact that it fits in a single page. */
@@ -2640,7 +2640,7 @@ static void kvm_steal_time_set_preempted(struct kvm_vcpu *vcpu)
if (unlikely(current->mm != vcpu->kvm->mm))
return;
- if (unlikely(!kvm_check_gen(vcpu->kvm, ghc->generation) ||
+ if (unlikely(!kvm_check_gen(vcpu->kvm, ghc->slots_generation, ghc->attrs_generation) ||
gpa != ghc->gpa ||
kvm_is_error_hva(ghc->hva) || !ghc->memslot))
return;
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 7599ab7ad7ef..ab62ce37bc18 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -878,6 +878,7 @@ struct kvm {
struct {
/* Protected by slots_lock (for writes) and RCU (for reads) */
struct xarray array;
+ u64 generation;
} mem_attrs;
#endif
char stats_id[KVM_STATS_NAME_SIZE];
@@ -2592,13 +2593,31 @@ static inline bool kvm_mem_attributes_may_exec(u64 attrs)
#define KVM_MEMORY_ATTRIBUTE_PROT \
(KVM_MEMORY_ATTRIBUTE_NR | KVM_MEMORY_ATTRIBUTE_NW | KVM_MEMORY_ATTRIBUTE_NX)
+#define KVM_MEMORY_ATTRIBUTE_NEEDS_SYNC_MASK KVM_MEMORY_ATTRIBUTE_PROT
+
static inline unsigned long kvm_get_memory_attributes(struct kvm *kvm, gfn_t gfn)
{
return xa_to_value(xa_load(&kvm->mem_attrs.array, gfn));
}
+static inline u64 kvm_mem_attributes_generation(struct kvm *kvm)
+{
+ RCU_LOCKDEP_WARN(!lockdep_is_held(&kvm->slots_lock) &&
+ !srcu_read_lock_held(&kvm->srcu),
+ "Suspicious memory attribute generation usage\n");
+
+ /*
+ * The acquire pairs with the release in kvm_vm_set_mem_attributes().
+ * Memory attributes should only be queried _after_ storing the
+ * generation number.
+ */
+ return smp_load_acquire(&kvm->mem_attrs.generation);
+}
+
bool kvm_range_has_memory_attributes(struct kvm *kvm, gfn_t start, gfn_t end,
unsigned long mask, unsigned long attrs);
+bool kvm_range_has_any_memory_attributes(struct kvm *kvm, gfn_t start, gfn_t end,
+ unsigned long mask);
bool kvm_arch_pre_set_memory_attributes(struct kvm *kvm,
struct kvm_gfn_range *range);
bool kvm_arch_post_set_memory_attributes(struct kvm *kvm,
@@ -2628,6 +2647,10 @@ static inline unsigned long kvm_get_memory_attributes(struct kvm *kvm, gfn_t gfn
{
return 0;
}
+static inline u64 kvm_mem_attributes_generation(struct kvm *kvm)
+{
+ return 0;
+}
#endif /* CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES */
static inline int kvm_mem_attributes_may_read_gfn(struct kvm *kvm, gfn_t gfn)
@@ -2644,16 +2667,19 @@ static inline int kvm_mem_attributes_may_write_gfn(struct kvm *kvm, gfn_t gfn)
return kvm_mem_attributes_may_write(attrs);
}
-static inline bool kvm_memslots_check_gen(struct kvm *kvm, u64 slots_generation, struct kvm_memslots **p_slots)
+static inline bool kvm_memslots_check_gen(struct kvm *kvm, u64 slots_generation,
+ u64 attrs_generation, struct kvm_memslots **p_slots)
{
struct kvm_memslots *slots = *p_slots = kvm_memslots(kvm);
- return slots->generation == slots_generation;
+ return slots->generation == slots_generation &&
+ kvm_mem_attributes_generation(kvm) == attrs_generation;
}
-static inline bool kvm_check_gen(struct kvm *kvm, u64 slots_generation)
+static inline bool kvm_check_gen(struct kvm *kvm, u64 slots_generation,
+ u64 attrs_generation)
{
struct kvm_memslots *slots;
- return kvm_memslots_check_gen(kvm, slots_generation, &slots);
+ return kvm_memslots_check_gen(kvm, slots_generation, attrs_generation, &slots);
}
diff --git a/include/linux/kvm_types.h b/include/linux/kvm_types.h
index a568d8e6f4e8..7d911220e00d 100644
--- a/include/linux/kvm_types.h
+++ b/include/linux/kvm_types.h
@@ -74,7 +74,8 @@ typedef u64 hfn_t;
typedef hfn_t kvm_pfn_t;
struct gfn_to_hva_cache {
- u64 generation;
+ u64 slots_generation;
+ u64 attrs_generation;
gpa_t gpa;
unsigned long hva;
unsigned long len;
@@ -82,7 +83,8 @@ struct gfn_to_hva_cache {
};
struct gfn_to_pfn_cache {
- u64 generation;
+ u64 slots_generation;
+ u64 attrs_generation;
gpa_t gpa;
unsigned long uhva;
struct kvm_memory_slot *memslot;
diff --git a/include/trace/events/kvm.h b/include/trace/events/kvm.h
index b282e3a86769..a620131e9010 100644
--- a/include/trace/events/kvm.h
+++ b/include/trace/events/kvm.h
@@ -365,23 +365,29 @@ TRACE_EVENT(kvm_dirty_ring_exit,
* @attr: The value of the attribute being set.
*/
TRACE_EVENT(kvm_vm_set_mem_attributes,
- TP_PROTO(gfn_t start, gfn_t end, unsigned long attr),
- TP_ARGS(start, end, attr),
+ TP_PROTO(gfn_t start, gfn_t end, unsigned long attr, bool sync, u64 generation),
+ TP_ARGS(start, end, attr, sync, generation),
TP_STRUCT__entry(
__field(gfn_t, start)
__field(gfn_t, end)
__field(unsigned long, attr)
+ __field(bool, sync)
+ __field(u64, generation)
),
TP_fast_assign(
__entry->start = start;
__entry->end = end;
__entry->attr = attr;
+ __entry->sync = sync;
+ __entry->generation = generation;
),
- TP_printk("%#016llx -- %#016llx [0x%lx]",
- __entry->start, __entry->end, __entry->attr)
+ TP_printk("%#016llx -- %#016llx [0x%lx], sync %d gen %llu",
+ __entry->start, __entry->end, __entry->attr,
+ __entry->sync, __entry->generation)
+
);
#endif /* CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES */
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 89e79d3f27f0..ea9f3e0625cb 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1118,6 +1118,7 @@ static struct kvm *kvm_create_vm(unsigned long type, const char *fdname)
xa_init(&kvm->vcpu_array);
#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
xa_init(&kvm->mem_attrs.array);
+ kvm->mem_attrs.generation = 0;
#endif
INIT_LIST_HEAD(&kvm->gpc_list);
@@ -2470,6 +2471,51 @@ bool kvm_range_has_memory_attributes(struct kvm *kvm, gfn_t start, gfn_t end,
return true;
}
+/*
+ * Returns true if _any_ gfns in the range [@start, @end) have attributes that
+ * match _any_ bit in @mask.
+ */
+bool kvm_range_has_any_memory_attributes(struct kvm *kvm, gfn_t start, gfn_t end,
+ unsigned long mask)
+{
+ XA_STATE(xas, &kvm->mem_attrs.array, start);
+ void *entry;
+
+ mask &= kvm_supported_mem_attributes(kvm);
+ if (!mask)
+ return false;
+
+ if (end == start + 1)
+ return !!(kvm_get_memory_attributes(kvm, start) & mask);
+
+ guard(rcu)();
+ for (;;) {
+ do {
+ entry = xas_next(&xas);
+ } while (xas_retry(&xas, entry));
+
+ if (xas.xa_index >= end)
+ break;
+
+ if (xa_to_value(entry) & mask)
+ return true;
+ }
+
+ return false;
+}
+
+static bool kvm_range_memory_attributes_need_sync(struct kvm *kvm,
+ gfn_t start, gfn_t end,
+ unsigned long attributes)
+{
+ u64 mask = KVM_MEMORY_ATTRIBUTE_NEEDS_SYNC_MASK;
+
+ if (attributes & mask)
+ return true;
+
+ return kvm_range_has_any_memory_attributes(kvm, start, end, mask);
+}
+
static __always_inline void kvm_handle_gfn_range(struct kvm *kvm,
struct kvm_mmu_notifier_range *range)
{
@@ -2562,20 +2608,25 @@ static int kvm_vm_set_mem_attributes(struct kvm *kvm, gfn_t start, gfn_t end,
.on_lock = kvm_mmu_invalidate_end,
.may_block = true,
};
+ bool sync = false;
unsigned long i;
void *entry;
int r = 0;
entry = attributes ? xa_mk_value(attributes) : NULL;
- trace_kvm_vm_set_mem_attributes(start, end, attributes);
-
mutex_lock(&kvm->slots_lock);
/* Nothing to do if the entire range has the desired attributes. */
if (kvm_range_has_memory_attributes(kvm, start, end, ~0, attributes))
goto out_unlock;
+ sync = kvm_range_memory_attributes_need_sync(kvm, start, end,
+ attributes);
+
+ trace_kvm_vm_set_mem_attributes(start, end, attributes, sync,
+ kvm->mem_attrs.generation + 1);
+
/*
* Reserve memory ahead of time to avoid having to deal with failures
* partway through setting the new attributes.
@@ -2597,10 +2648,16 @@ static int kvm_vm_set_mem_attributes(struct kvm *kvm, gfn_t start, gfn_t end,
cond_resched();
}
+ /* Pairs with acquire in kvm_mem_attributes_generation() */
+ smp_store_release(&kvm->mem_attrs.generation,
+ kvm->mem_attrs.generation + 1);
+
kvm_handle_gfn_range(kvm, &post_set_range);
out_unlock:
mutex_unlock(&kvm->slots_lock);
+ if (sync)
+ synchronize_srcu_expedited(&kvm->srcu);
return r;
}
@@ -3470,7 +3527,8 @@ int kvm_vcpu_write_guest(struct kvm_vcpu *vcpu, gpa_t gpa, const void *data,
}
EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_vcpu_write_guest);
-static int __kvm_gfn_to_hva_cache_init(struct kvm_memslots *slots,
+static int __kvm_gfn_to_hva_cache_init(struct kvm *kvm,
+ struct kvm_memslots *slots,
struct gfn_to_hva_cache *ghc,
gpa_t gpa, unsigned long len)
{
@@ -3480,8 +3538,8 @@ static int __kvm_gfn_to_hva_cache_init(struct kvm_memslots *slots,
gfn_t nr_pages_needed = end_gfn - start_gfn + 1;
gfn_t nr_pages_avail;
- /* Update ghc->generation before performing any error checks. */
- ghc->generation = slots->generation;
+ /* Update ghc->slots_generation before performing any error checks. */
+ ghc->slots_generation = slots->generation;
if (start_gfn > end_gfn) {
ghc->hva = KVM_HVA_ERR_BAD;
@@ -3500,6 +3558,8 @@ static int __kvm_gfn_to_hva_cache_init(struct kvm_memslots *slots,
return -EFAULT;
}
+ ghc->attrs_generation = kvm_mem_attributes_generation(kvm);
+
/* Use the slow path for cross page reads and writes. */
if (nr_pages_needed == 1)
ghc->hva += offset;
@@ -3515,7 +3575,7 @@ int kvm_gfn_to_hva_cache_init(struct kvm *kvm, struct gfn_to_hva_cache *ghc,
gpa_t gpa, unsigned long len)
{
struct kvm_memslots *slots = kvm_memslots(kvm);
- return __kvm_gfn_to_hva_cache_init(slots, ghc, gpa, len);
+ return __kvm_gfn_to_hva_cache_init(kvm, slots, ghc, gpa, len);
}
EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_gfn_to_hva_cache_init);
@@ -3530,8 +3590,8 @@ int kvm_write_guest_offset_cached(struct kvm *kvm, struct gfn_to_hva_cache *ghc,
if (WARN_ON_ONCE(len + offset > ghc->len))
return -EINVAL;
- if (unlikely(!kvm_memslots_check_gen(kvm, ghc->generation, &slots))) {
- if (__kvm_gfn_to_hva_cache_init(slots, ghc, ghc->gpa, ghc->len))
+ if (unlikely(!kvm_memslots_check_gen(kvm, ghc->slots_generation, ghc->attrs_generation, &slots))) {
+ if (__kvm_gfn_to_hva_cache_init(kvm, slots, ghc, ghc->gpa, ghc->len))
return -EFAULT;
}
@@ -3568,8 +3628,8 @@ int kvm_read_guest_offset_cached(struct kvm *kvm, struct gfn_to_hva_cache *ghc,
if (WARN_ON_ONCE(len + offset > ghc->len))
return -EINVAL;
- if (unlikely(!kvm_memslots_check_gen(kvm, ghc->generation, &slots))) {
- if (__kvm_gfn_to_hva_cache_init(slots, ghc, ghc->gpa, ghc->len))
+ if (unlikely(!kvm_memslots_check_gen(kvm, ghc->slots_generation, ghc->attrs_generation, &slots))) {
+ if (__kvm_gfn_to_hva_cache_init(kvm, slots, ghc, ghc->gpa, ghc->len))
return -EFAULT;
}
diff --git a/virt/kvm/pfncache.c b/virt/kvm/pfncache.c
index e09703d249bb..46ffae69fe77 100644
--- a/virt/kvm/pfncache.c
+++ b/virt/kvm/pfncache.c
@@ -76,10 +76,11 @@ bool kvm_gpc_check(struct gfn_to_pfn_cache *gpc, unsigned long len)
return false;
/*
- * If the page was cached from a memslot, make sure the memslots have
- * not been re-configured.
+ * If the page was cached from a memslot, make sure the memslots nor
+ * memory attributes have not been re-configured.
*/
- if (!kvm_is_error_gpa(gpc->gpa) && !kvm_check_gen(gpc->kvm, gpc->generation))
+ if (!kvm_is_error_gpa(gpc->gpa) &&
+ !kvm_check_gen(gpc->kvm, gpc->slots_generation, gpc->attrs_generation))
return false;
if (kvm_is_error_hva(gpc->uhva))
@@ -253,6 +254,7 @@ static kvm_pfn_t hva_to_pfn_retry(struct gfn_to_pfn_cache *gpc)
static int __kvm_gpc_refresh(struct gfn_to_pfn_cache *gpc, gpa_t gpa, unsigned long uhva)
{
+ struct kvm *kvm = gpc->kvm;
unsigned long page_offset;
bool unmap_old = false;
unsigned long old_uhva;
@@ -292,12 +294,13 @@ static int __kvm_gpc_refresh(struct gfn_to_pfn_cache *gpc, gpa_t gpa, unsigned l
page_offset = offset_in_page(gpa);
- if (!kvm_memslots_check_gen(gpc->kvm, gpc->generation, &slots) ||
+ if (!kvm_memslots_check_gen(gpc->kvm, gpc->slots_generation, gpc->attrs_generation, &slots) ||
gpc->gpa != gpa || kvm_is_error_hva(gpc->uhva)) {
gfn_t gfn = gpa_to_gfn(gpa);
+ gpc->attrs_generation = kvm_mem_attributes_generation(kvm);
gpc->gpa = gpa;
- gpc->generation = slots->generation;
+ gpc->slots_generation = slots->generation;
gpc->memslot = __gfn_to_memslot(slots, gfn);
gpc->uhva = gfn_to_hva_memslot(gpc->memslot, gfn);
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* Re: [PATCH v2 18/28] KVM: Introduce a generation number for memory attributes
2026-09-18 8:15 ` [PATCH v2 18/28] KVM: Introduce a generation number for memory attributes Paolo Bonzini
@ 2026-09-18 8:39 ` sashiko-bot
0 siblings, 0 replies; 44+ messages in thread
From: sashiko-bot @ 2026-09-18 8:39 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: kvm
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] kvm: RCU stall in kvm_range_has_any_memory_attributes() due to XArray bounds mishandling
- [High] kvm: LoongArch compilation failure due to removed generation field
--
commit fa1df61c99941c6c01fe6e64de2dd5831dc8ad7d
Author: Nicolas Saenz Julienne <nsaenz@amazon.com>
KVM: Introduce a generation number for memory attributes
This commit introduces a generation number to track memory attribute
modifications. It ensures that cached guest physical addresses and
permissions are validated against this generation before access.
> diff --git a/include/linux/kvm_types.h b/include/linux/kvm_types.h
> index a568d8e6f4e82..7d911220e00d2 100644
> --- a/include/linux/kvm_types.h
> +++ b/include/linux/kvm_types.h
> @@ -74,7 +74,8 @@ typedef u64 hfn_t;
> typedef hfn_t kvm_pfn_t;
>
> struct gfn_to_hva_cache {
> - u64 generation;
> + u64 slots_generation;
> + u64 attrs_generation;
> gpa_t gpa;
> unsigned long hva;
[Severity: High]
Does this change cause a compilation failure on LoongArch builds?
It looks like kvm_update_stolen_time() in arch/loongarch/kvm/vcpu.c still
contains a direct reference to the removed generation field:
if (slots->generation != ghc->generation || gpa != ghc->gpa) {
Should this architecture-specific file be updated to check the new
slots_generation and attrs_generation fields?
[ ... ]
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index eede017d41411..2d85d7c9e0046 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2480,6 +2481,51 @@ bool kvm_range_has_memory_attributes(struct kvm *kvm, gfn_t start, gfn_t end,
> return true;
> }
>
> +/*
> + * Returns true if _any_ gfns in the range [@start, @end) have attributes that
> + * match _any_ bit in @mask.
> + */
> +bool kvm_range_has_any_memory_attributes(struct kvm *kvm, gfn_t start, gfn_t end,
> + unsigned long mask)
> +{
> + XA_STATE(xas, &kvm->mem_attrs.array, start);
> + void *entry;
> +
> + mask &= kvm_supported_mem_attributes(kvm);
> + if (!mask)
> + return false;
> +
> + if (end == start + 1)
> + return !!(kvm_get_memory_attributes(kvm, start) & mask);
> +
> + guard(rcu)();
> + for (;;) {
> + do {
> + entry = xas_next(&xas);
> + } while (xas_retry(&xas, entry));
> +
> + if (xas.xa_index >= end)
> + break;
[Severity: High]
Can this loop stall infinitely if a user provides a range that extends
beyond the populated indices of the mem_attrs XArray?
If xas_next() goes out of bounds, it returns NULL and sets the state to
XAS_BOUNDS, which means xas.xa_index stops advancing. Because the loop
relies strictly on xas.xa_index >= end to terminate, an out-of-bounds
query would never break out of the loop and cause an RCU stall.
> +
> + if (xa_to_value(entry) & mask)
> + return true;
> + }
> +
> + return false;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918081543.139871-1-pbonzini@redhat.com?part=18
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v2 19/28] KVM: Take memory protections into account for accesses with cached gfn->hva
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
` (17 preceding siblings ...)
2026-09-18 8:15 ` [PATCH v2 18/28] KVM: Introduce a generation number for memory attributes Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:38 ` sashiko-bot
2026-09-18 8:15 ` [PATCH v2 20/28] KVM: pfncache: Fail to refresh if it contains memory protections Paolo Bonzini
` (8 subsequent siblings)
27 siblings, 1 reply; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
From: Nicolas Saenz Julienne <nsaenz@amazon.com>
Account for memory attributes when accessing guest memory through
kvm_get/put_guest().
This requires tracking the memory attributes generation as part of
gfn_to_hva_cache's data, invalidate the cached information if the
generation changes, and failing to refresh the cache if restrictive
memory attributes are found within the GPA range.
Similar to how gfn_to_hva_cache disallows caching gfns mapped within
read-only memory slots, gfns marked as read-only by memory attributes
will also fail to initialize. Unsurprisingly, the same behaviour applies
to gfns mapped as non-accessible (NR/NW), while non-executable mappings
are okay.
Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
include/linux/kvm_host.h | 20 +++++++++++++++++---
virt/kvm/kvm_main.c | 15 +++++++++++----
2 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index ab62ce37bc18..e9c0932f150e 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -1359,7 +1359,8 @@ int kvm_gfn_to_hva_cache_init(struct kvm *kvm, struct gfn_to_hva_cache *ghc,
typeof(v) __user *__uaddr = (typeof(__uaddr))(__addr + offset); \
int __ret = -EFAULT; \
\
- if (!kvm_is_error_hva(__addr)) \
+ if (!kvm_is_error_hva(__addr) && \
+ kvm_mem_attributes_may_read_gfn(kvm, gfn)) \
__ret = get_user(v, __uaddr); \
__ret; \
})
@@ -1379,7 +1380,8 @@ int kvm_gfn_to_hva_cache_init(struct kvm *kvm, struct gfn_to_hva_cache *ghc,
typeof(v) __user *__uaddr = (typeof(__uaddr))(__addr + offset); \
int __ret = -EFAULT; \
\
- if (!kvm_is_error_hva(__addr)) \
+ if (!kvm_is_error_hva(__addr) && \
+ kvm_mem_attributes_may_write_gfn(kvm, gfn)) \
__ret = put_user(v, __uaddr); \
if (!__ret) \
mark_page_dirty(kvm, gfn); \
@@ -2647,6 +2649,12 @@ static inline unsigned long kvm_get_memory_attributes(struct kvm *kvm, gfn_t gfn
{
return 0;
}
+static inline bool kvm_range_has_any_memory_attributes(struct kvm *kvm,
+ gfn_t start, gfn_t end,
+ unsigned long mask)
+{
+ return false;
+}
static inline u64 kvm_mem_attributes_generation(struct kvm *kvm)
{
return 0;
@@ -2667,6 +2675,13 @@ static inline int kvm_mem_attributes_may_write_gfn(struct kvm *kvm, gfn_t gfn)
return kvm_mem_attributes_may_write(attrs);
}
+static inline bool kvm_range_has_rw_memory_protections(struct kvm *kvm,
+ gfn_t start, gfn_t end)
+{
+ return kvm_range_has_any_memory_attributes(kvm, start, end,
+ KVM_MEMORY_ATTRIBUTE_NR | KVM_MEMORY_ATTRIBUTE_NW);
+}
+
static inline bool kvm_memslots_check_gen(struct kvm *kvm, u64 slots_generation,
u64 attrs_generation, struct kvm_memslots **p_slots)
{
@@ -2682,7 +2697,6 @@ static inline bool kvm_check_gen(struct kvm *kvm, u64 slots_generation,
return kvm_memslots_check_gen(kvm, slots_generation, attrs_generation, &slots);
}
-
#ifdef CONFIG_KVM_GUEST_MEMFD
int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory_slot *slot,
gfn_t gfn, kvm_pfn_t *pfn, struct page **page,
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index ea9f3e0625cb..24f46dce192e 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3550,15 +3550,22 @@ static int __kvm_gfn_to_hva_cache_init(struct kvm *kvm,
* If the requested region crosses two memslots, we still
* verify that the entire region is valid here.
*/
- for ( ; start_gfn <= end_gfn; start_gfn += nr_pages_avail) {
- ghc->memslot = __gfn_to_memslot(slots, start_gfn);
- ghc->hva = gfn_to_hva_many(ghc->memslot, start_gfn,
- &nr_pages_avail);
+ for (gfn_t gfn = start_gfn ; gfn <= end_gfn; gfn += nr_pages_avail) {
+ ghc->memslot = __gfn_to_memslot(slots, gfn);
+ ghc->hva = gfn_to_hva_many(ghc->memslot, gfn, &nr_pages_avail);
if (kvm_is_error_hva(ghc->hva))
return -EFAULT;
}
+ /*
+ * RW memory attributes are incompatible with GHC. The RW protection
+ * check has to happen after storing the generation number.
+ */
ghc->attrs_generation = kvm_mem_attributes_generation(kvm);
+ if (kvm_range_has_rw_memory_protections(kvm, start_gfn, end_gfn + 1)) {
+ ghc->hva = KVM_HVA_ERR_BAD;
+ return -EFAULT;
+ }
/* Use the slow path for cross page reads and writes. */
if (nr_pages_needed == 1)
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* Re: [PATCH v2 19/28] KVM: Take memory protections into account for accesses with cached gfn->hva
2026-09-18 8:15 ` [PATCH v2 19/28] KVM: Take memory protections into account for accesses with cached gfn->hva Paolo Bonzini
@ 2026-09-18 8:38 ` sashiko-bot
0 siblings, 0 replies; 44+ messages in thread
From: sashiko-bot @ 2026-09-18 8:38 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: kvm
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] kvm: loongarch build failure due to unrenamed ghc->generation field
--
commit d698f3639de00de4e2127e86617e1f29da8afef7
Author: Nicolas Saenz Julienne <nsaenz@amazon.com>
KVM: Take memory protections into account for accesses with cached gfn->hva
Account for memory attributes when accessing guest memory through
kvm_get/put_guest().
This requires tracking the memory attributes generation as part of
gfn_to_hva_cache's data, invalidate the cached information if the
generation changes, and failing to refresh the cache if restrictive
memory attributes are found within the GPA range.
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 2d85d7c9e0046..f10b14293e60e 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
[ ... ]
> @@ -3560,15 +3560,22 @@ static int __kvm_gfn_to_hva_cache_init(struct kvm *kvm,
> * If the requested region crosses two memslots, we still
> * verify that the entire region is valid here.
> */
> - for ( ; start_gfn <= end_gfn; start_gfn += nr_pages_avail) {
> - ghc->memslot = __gfn_to_memslot(slots, start_gfn);
> - ghc->hva = gfn_to_hva_many(ghc->memslot, start_gfn,
> - &nr_pages_avail);
> + for (gfn_t gfn = start_gfn ; gfn <= end_gfn; gfn += nr_pages_avail) {
> + ghc->memslot = __gfn_to_memslot(slots, gfn);
> + ghc->hva = gfn_to_hva_many(ghc->memslot, gfn, &nr_pages_avail);
> if (kvm_is_error_hva(ghc->hva))
> return -EFAULT;
> }
>
> + /*
> + * RW memory attributes are incompatible with GHC. The RW protection
> + * check has to happen after storing the generation number.
> + */
> ghc->attrs_generation = kvm_mem_attributes_generation(kvm);
[Severity: Low]
Does this patchset break the build on LoongArch?
In arch/loongarch/kvm/vcpu.c, kvm_update_stolen_time() and
kvm_vcpu_set_pv_preempted() still reference the removed ghc->generation field
and fail to verify memory attribute generations:
arch/loongarch/kvm/vcpu.c:kvm_update_stolen_time() {
...
if (slots->generation != ghc->generation || gpa != ghc->gpa) {
...
}
arch/loongarch/kvm/vcpu.c:kvm_vcpu_set_pv_preempted() {
...
if (slots->generation != ghc->generation || gpa != ghc->gpa) {
...
}
With the transition to ghc->attrs_generation and ghc->slots_generation across
this patchset (specifically since the prior patch "KVM: Introduce a generation
number for memory attributes"), these manual generation checks will fail to
compile.
Could these be updated to use kvm_check_gen()?
> + if (kvm_range_has_rw_memory_protections(kvm, start_gfn, end_gfn + 1)) {
> + ghc->hva = KVM_HVA_ERR_BAD;
> + return -EFAULT;
> + }
>
> /* Use the slow path for cross page reads and writes. */
> if (nr_pages_needed == 1)
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918081543.139871-1-pbonzini@redhat.com?part=19
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v2 20/28] KVM: pfncache: Fail to refresh if it contains memory protections
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
` (18 preceding siblings ...)
2026-09-18 8:15 ` [PATCH v2 19/28] KVM: Take memory protections into account for accesses with cached gfn->hva Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:15 ` [PATCH v2 21/28] KVM: x86/mmu: Take memory protection attributes into account during faults Paolo Bonzini
` (7 subsequent siblings)
27 siblings, 0 replies; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
From: Nicolas Saenz Julienne <nsaenz@amazon.com>
Similar to how pfncache disallows caching gfns mapped within read-only
memory slots, gfns marked as read-only by memory attributes must
fail to initialize. Unsurprisingly, the same behaviour applies to gfns
mapped as non-accessible (NR/NW), while non-executable mappings are fine.
Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
virt/kvm/pfncache.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/virt/kvm/pfncache.c b/virt/kvm/pfncache.c
index 46ffae69fe77..39935740136d 100644
--- a/virt/kvm/pfncache.c
+++ b/virt/kvm/pfncache.c
@@ -298,7 +298,18 @@ static int __kvm_gpc_refresh(struct gfn_to_pfn_cache *gpc, gpa_t gpa, unsigned l
gpc->gpa != gpa || kvm_is_error_hva(gpc->uhva)) {
gfn_t gfn = gpa_to_gfn(gpa);
+ /*
+ * RW memory attributes are incompatible with GPC. The
+ * RW protection check has to happen after storing the
+ * generation number.
+ */
gpc->attrs_generation = kvm_mem_attributes_generation(kvm);
+ if (kvm_range_has_rw_memory_protections(kvm, gfn, gfn + 1)) {
+ gpc->uhva = KVM_HVA_ERR_BAD;
+ ret = -EFAULT;
+ goto out;
+ }
+
gpc->gpa = gpa;
gpc->slots_generation = slots->generation;
gpc->memslot = __gfn_to_memslot(slots, gfn);
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v2 21/28] KVM: x86/mmu: Take memory protection attributes into account during faults
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
` (19 preceding siblings ...)
2026-09-18 8:15 ` [PATCH v2 20/28] KVM: pfncache: Fail to refresh if it contains memory protections Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:46 ` sashiko-bot
2026-09-18 8:15 ` [PATCH v2 22/28] KVM: x86/mmu: Issue memory fault exit if walk failed due to memory attribute Paolo Bonzini
` (6 subsequent siblings)
27 siblings, 1 reply; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
From: Nicolas Saenz Julienne <nsaenz@amazon.com>
Take memory protection attributes when faulting guest memory. Prohibited
memory accesses will cause a user-space -EFAULT exit just like private
memory accesses. Userspace will either enable the access or bump it to
the guest as some kind of exception (e.g. a VTL return).
Since the struct kvm_page_fault already has the access type in PFERR_*
format, the check is done via the kvm_page_format permissions table.
This means that it supports naturally all page table format variants,
and it can even handle mode-based memory protection when the host
uses MBEC/GMET. The only thing that needs some care is to build the
restricted ACC_* mask with the root page's own access mask as a base
(and not ACC_ALL). Otherwise, supervisor mode execution would be
handled incorrectly on AMD processors with GMET.
To avoid spamming the trace buffer too much, the new trace event only
kicks in if memory protection attributes are present for the faulted gfn.
Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/kvm/mmu/mmu.c | 49 +++++++++++++++++++++++++++++++++
arch/x86/kvm/mmu/mmu_internal.h | 19 +++++++++++++
arch/x86/kvm/mmu/mmutrace.h | 36 ++++++++++++++++++++++++
arch/x86/kvm/mmu/paging_tmpl.h | 2 +-
arch/x86/kvm/mmu/spte.h | 11 ++------
5 files changed, 107 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 797b18201d98..3fd4cc3c57a5 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -4642,6 +4642,50 @@ static int kvm_mmu_faultin_pfn_gmem(struct kvm_vcpu *vcpu,
return RET_PF_CONTINUE;
}
+static inline unsigned kvm_get_gfn_protections(struct kvm_vcpu *vcpu, gfn_t gfn)
+{
+ struct kvm *kvm = vcpu->kvm;
+ unsigned int access = vcpu->arch.mmu->root_role.access;
+ unsigned long attrs = kvm_get_memory_attributes(kvm, gfn);
+ if (!attrs)
+ return access;
+
+ WARN_ON_ONCE(!kvm_mem_attributes_valid(kvm, attrs));
+
+ if (!kvm_mem_attributes_may_read(attrs))
+ access &= ~ACC_READ_MASK;
+ if (!kvm_mem_attributes_may_write(attrs))
+ access &= ~ACC_WRITE_MASK;
+ if (!kvm_mem_attributes_may_exec(attrs)) {
+ access &= ~ACC_EXEC_MASK;
+ if (shadow_xu_mask)
+ access &= ~ACC_USER_EXEC_MASK;
+ }
+
+ return access;
+}
+
+static int kvm_faultin_memory_protections(struct kvm_vcpu *vcpu,
+ struct kvm_page_fault *fault)
+{
+ unsigned access;
+
+ /* Memory attributes don't apply to MMIO regions */
+ if (unlikely(!fault->slot))
+ return RET_PF_CONTINUE;
+
+ access = kvm_get_gfn_protections(vcpu, fault->gfn);
+ if (access == ACC_ALL)
+ return RET_PF_CONTINUE;
+
+ trace_kvm_faultin_memory_protections(vcpu, fault, access);
+ if (__permission_fault(vcpu->arch.mmu, access, fault))
+ return -EFAULT;
+
+ fault->host_access &= access;
+ return RET_PF_CONTINUE;
+}
+
static int __kvm_mmu_faultin_pfn(struct kvm_vcpu *vcpu,
struct kvm_page_fault *fault)
{
@@ -4722,6 +4766,11 @@ static int kvm_mmu_faultin_pfn(struct kvm_vcpu *vcpu,
if (unlikely(!slot))
return kvm_handle_noslot_fault(vcpu, fault, access);
+ if (kvm_faultin_memory_protections(vcpu, fault)) {
+ kvm_mmu_prepare_memory_fault_exit(vcpu, fault);
+ return -EFAULT;
+ }
+
/*
* Retry the page fault if the gfn hit a memslot that is being deleted
* or moved. This ensures any existing SPTEs for the old memslot will
diff --git a/arch/x86/kvm/mmu/mmu_internal.h b/arch/x86/kvm/mmu/mmu_internal.h
index 00215b9f309f..0bad60c5aab6 100644
--- a/arch/x86/kvm/mmu/mmu_internal.h
+++ b/arch/x86/kvm/mmu/mmu_internal.h
@@ -290,6 +290,25 @@ struct kvm_page_fault {
bool write_fault_to_shadow_pgtable;
};
+/*
+ * Returns true if the access indicated by @fault is forbidden by the existing
+ * SPTE protections.
+ */
+static inline bool __permission_fault(struct kvm_mmu *mmu, unsigned access,
+ struct kvm_page_fault *fault)
+{
+ unsigned pfec;
+
+ /*
+ * RSVD is handled elsewhere, and is used for SMAP in the context
+ * of accessing fmt.permissions[]. SPTEs never use PK or SS, as
+ * they are not supported for shadow paging and irrelevant for TDP.
+ */
+ pfec = fault->error_code & (
+ PFERR_WRITE_MASK | PFERR_USER_MASK | PFERR_FETCH_MASK);
+ return (mmu->fmt.permissions[pfec >> 1] >> access) & 1;
+}
+
/*
* Return values of handle_mmio_page_fault(), mmu.page_fault(), fast_page_fault(),
* and of course kvm_mmu_do_page_fault().
diff --git a/arch/x86/kvm/mmu/mmutrace.h b/arch/x86/kvm/mmu/mmutrace.h
index 8354d9f39777..744f111644cb 100644
--- a/arch/x86/kvm/mmu/mmutrace.h
+++ b/arch/x86/kvm/mmu/mmutrace.h
@@ -8,6 +8,13 @@
#undef TRACE_SYSTEM
#define TRACE_SYSTEM kvmmmu
+#ifdef CREATE_TRACE_POINTS
+#define tracing_kvm_rip_read(vcpu) ({ \
+ typeof(vcpu) __vcpu = vcpu; \
+ __vcpu->arch.guest_state_protected ? 0 : kvm_rip_read(__vcpu); \
+ })
+#endif
+
#define KVM_MMU_PAGE_FIELDS \
__field(__u8, mmu_valid_gen) \
__field(__u64, gfn) \
@@ -447,6 +454,35 @@ TRACE_EVENT(
__entry->gfn, __entry->spte, __entry->level, __entry->errno)
);
+TRACE_EVENT(kvm_faultin_memory_protections,
+ TP_PROTO(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault,
+ unsigned access),
+ TP_ARGS(vcpu, fault, access),
+
+ TP_STRUCT__entry(
+ __field(unsigned int, vcpu_id)
+ __field(unsigned long, guest_rip)
+ __field(u64, fault_address)
+ __field(bool, write)
+ __field(bool, exec)
+ __field(unsigned, access)
+ ),
+
+ TP_fast_assign(
+ __entry->vcpu_id = vcpu->vcpu_id;
+ __entry->guest_rip = tracing_kvm_rip_read(vcpu);
+ __entry->fault_address = fault->gfn;
+ __entry->write = fault->write;
+ __entry->exec = fault->exec;
+ __entry->access = access;
+ ),
+
+ TP_printk("vcpu %d rip 0x%lx gfn 0x%016llx access %s protections 0x%x",
+ __entry->vcpu_id, __entry->guest_rip, __entry->fault_address,
+ __entry->exec ? "X" : (__entry->write ? "W" : "R"),
+ __entry->access)
+);
+
#endif /* _TRACE_KVMMMU_H */
#undef TRACE_INCLUDE_PATH
diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h
index e6ec14165f40..b031123fcb36 100644
--- a/arch/x86/kvm/mmu/paging_tmpl.h
+++ b/arch/x86/kvm/mmu/paging_tmpl.h
@@ -992,7 +992,7 @@ static int FNAME(sync_spte)(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp, int
sptep = &sp->spt[i];
spte = *sptep;
- host_access = ACC_ALL;
+ host_access = kvm_get_gfn_protections(vcpu, gfn);
if (!(spte & shadow_host_writable_mask))
host_access &= ~ACC_WRITE_MASK;
slot = kvm_vcpu_gfn_to_memslot(vcpu, gfn);
diff --git a/arch/x86/kvm/mmu/spte.h b/arch/x86/kvm/mmu/spte.h
index 589f3954633e..14f322944671 100644
--- a/arch/x86/kvm/mmu/spte.h
+++ b/arch/x86/kvm/mmu/spte.h
@@ -491,7 +491,7 @@ static inline bool is_mmu_writable_spte(u64 spte)
static inline bool spte_permission_fault(struct kvm_mmu *mmu, u64 spte,
struct kvm_page_fault *fault)
{
- unsigned pfec, pte_access;
+ unsigned pte_access;
if (!is_shadow_present_pte(spte))
return true;
@@ -511,14 +511,7 @@ static inline bool spte_permission_fault(struct kvm_mmu *mmu, u64 spte,
pte_access |= spte & shadow_xu_mask ? ACC_USER_EXEC_MASK : 0;
}
- /*
- * RSVD is handled elsewhere, and is used for SMAP in the context
- * of accessing fmt.permissions[]. SPTEs never use PK or SS, as
- * they are not supported for shadow paging and irrelevant for TDP.
- */
- pfec = fault->error_code & (
- PFERR_WRITE_MASK | PFERR_USER_MASK | PFERR_FETCH_MASK);
- return (mmu->fmt.permissions[pfec >> 1] >> pte_access) & 1;
+ return __permission_fault(mmu, pte_access, fault);
}
/*
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* Re: [PATCH v2 21/28] KVM: x86/mmu: Take memory protection attributes into account during faults
2026-09-18 8:15 ` [PATCH v2 21/28] KVM: x86/mmu: Take memory protection attributes into account during faults Paolo Bonzini
@ 2026-09-18 8:46 ` sashiko-bot
0 siblings, 0 replies; 44+ messages in thread
From: sashiko-bot @ 2026-09-18 8:46 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: kvm
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Critical] kvm: mmu: prefetching completely bypasses memory protections
- [Critical] kvm: mmu: missing SPTE invalidation allows bypass of shared memory protections
- [High] kvm: mmu: host access permissions conflated with guest root_role.access
--
commit 5aa6405feba846a8b81344070caa806c21c16bfd
Author: Nicolas Saenz Julienne <nsaenz@amazon.com>
Subject: KVM: x86/mmu: Take memory protection attributes into account during faults
This commit updates KVM x86 MMU to respect memory protection attributes when
faulting guest memory. Prohibited accesses will cause a user-space -EFAULT
exit. The access type is checked using the existing kvm_page_format
permissions table.
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 797b18201d982..3fd4cc3c57a53 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -4642,6 +4642,50 @@ static int kvm_mmu_faultin_pfn_gmem(struct kvm_vcpu *vcpu,
> return RET_PF_CONTINUE;
> }
>
> +static inline unsigned kvm_get_gfn_protections(struct kvm_vcpu *vcpu, gfn_t gfn)
> +{
> + struct kvm *kvm = vcpu->kvm;
> + unsigned int access = vcpu->arch.mmu->root_role.access;
> + unsigned long attrs = kvm_get_memory_attributes(kvm, gfn);
> + if (!attrs)
> + return access;
[Severity: High]
Does initializing host access rules with the guest's root_role.access conflate
host and guest permissions, potentially causing spurious -EFAULT exits?
If attrs is 0, this returns the guest mask. Then in
kvm_faultin_memory_protections(), this access mask is evaluated against the
hardware fault code using __permission_fault().
If the guest's root page table is restricted (e.g., lacks write access), any
guest write fault could return -EFAULT, causing a KVM_EXIT_MEMORY_FAULT to
userspace instead of injecting a normal guest #PF. A guest could trigger this
by executing code with restricted root page table permissions.
> +
> + WARN_ON_ONCE(!kvm_mem_attributes_valid(kvm, attrs));
> +
> + if (!kvm_mem_attributes_may_read(attrs))
> + access &= ~ACC_READ_MASK;
> + if (!kvm_mem_attributes_may_write(attrs))
> + access &= ~ACC_WRITE_MASK;
> + if (!kvm_mem_attributes_may_exec(attrs)) {
> + access &= ~ACC_EXEC_MASK;
> + if (shadow_xu_mask)
> + access &= ~ACC_USER_EXEC_MASK;
> + }
> +
> + return access;
> +}
> +
> +static int kvm_faultin_memory_protections(struct kvm_vcpu *vcpu,
> + struct kvm_page_fault *fault)
> +{
> + unsigned access;
> +
> + /* Memory attributes don't apply to MMIO regions */
> + if (unlikely(!fault->slot))
> + return RET_PF_CONTINUE;
> +
> + access = kvm_get_gfn_protections(vcpu, fault->gfn);
> + if (access == ACC_ALL)
> + return RET_PF_CONTINUE;
> +
> + trace_kvm_faultin_memory_protections(vcpu, fault, access);
> + if (__permission_fault(vcpu->arch.mmu, access, fault))
> + return -EFAULT;
> +
> + fault->host_access &= access;
> + return RET_PF_CONTINUE;
> +}
[Severity: Critical]
When memory protections are applied to shared memory, do we properly invalidate
existing writable SPTEs so that guests cannot bypass the protections?
Looking at kvm_arch_pre_set_memory_attributes() in arch/x86/kvm/mmu/mmu.c:
/* Unmap the old attribute page. */
if (range->arg.attributes & KVM_MEMORY_ATTRIBUTE_PRIVATE)
range->attr_filter = KVM_FILTER_SHARED;
else
range->attr_filter = KVM_FILTER_PRIVATE;
return kvm_unmap_gfn_range(kvm, range);
If userspace sets memory protections (like KVM_MEMORY_ATTRIBUTE_NW) without
setting PRIVATE, the filter falls back to KVM_FILTER_PRIVATE. The subsequent
call to kvm_unmap_gfn_range() only zaps private KVM_MIRROR_ROOTS and completely
skips shared KVM_DIRECT_ROOTS.
This could allow a guest to retain full read/write/execute access via existing
shared SPTEs to memory that was explicitly restricted by userspace.
[ ... ]
> diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h
> index e6ec14165f400..b031123fcb369 100644
> --- a/arch/x86/kvm/mmu/paging_tmpl.h
> +++ b/arch/x86/kvm/mmu/paging_tmpl.h
> @@ -992,7 +992,7 @@ static int FNAME(sync_spte)(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp, int
>
> sptep = &sp->spt[i];
> spte = *sptep;
> - host_access = ACC_ALL;
> + host_access = kvm_get_gfn_protections(vcpu, gfn);
[Severity: Critical]
Since we are replacing ACC_ALL with kvm_get_gfn_protections() here, does
mmu_set_spte() also need to be updated to prevent prefetching from bypassing
memory protections?
Looking at mmu_set_spte() in arch/x86/kvm/mmu/mmu.c:
unsigned host_access = fault ? fault->host_access : ACC_ALL;
If a guest touches a page adjacent to a protected page, triggering
kvm_mmu_prefetch_sptes(), mmu_set_spte() is called with a NULL fault pointer.
This causes it to default to ACC_ALL instead of querying the host attributes,
which could allow a malicious guest to bypass NR/NW/NX protections.
(Note: Patch 24 in this series attempts to fix this but introduces an inverted
condition "if (!kvm_get_memory_attributes(kvm, gfn)) continue;", which skips
prefetching only when there are NO attributes, and still grants ACC_ALL to
pages WITH attributes.)
> if (!(spte & shadow_host_writable_mask))
> host_access &= ~ACC_WRITE_MASK;
> slot = kvm_vcpu_gfn_to_memslot(vcpu, gfn);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918081543.139871-1-pbonzini@redhat.com?part=21
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v2 22/28] KVM: x86/mmu: Issue memory fault exit if walk failed due to memory attribute
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
` (20 preceding siblings ...)
2026-09-18 8:15 ` [PATCH v2 21/28] KVM: x86/mmu: Take memory protection attributes into account during faults Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:37 ` sashiko-bot
2026-09-18 8:15 ` [PATCH v2 23/28] KVM: x86/mmu: Do not update accessed/dirty if guest PTE is read-only Paolo Bonzini
` (5 subsequent siblings)
27 siblings, 1 reply; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
From: Nicolas Saenz Julienne <nsaenz@amazon.com>
During execution, page table entries are subject to memory protection
simply because their GPA is obtained with an EPT walk. During emulation,
the checks need to be done by hand and result in an -EFAULT userspace
exit.
Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/kvm/mmu/paging_tmpl.h | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h
index b031123fcb36..d2836a327bc9 100644
--- a/arch/x86/kvm/mmu/paging_tmpl.h
+++ b/arch/x86/kvm/mmu/paging_tmpl.h
@@ -89,6 +89,7 @@ struct guest_walker {
unsigned int pt_access[PT_MAX_FULL_LEVELS];
unsigned int pte_access;
gfn_t gfn;
+ bool memory_attributes_fault;
struct x86_exception fault;
};
@@ -342,6 +343,7 @@ static int FNAME(walk_addr_generic)(struct guest_walker *walker,
trace_kvm_mmu_pagetable_walk(addr, access);
retry_walk:
+ walker->memory_attributes_fault = false;
walker->level = w->cpu_role.base.level;
pte = kvm_mmu_get_guest_pgd(vcpu, w);
have_ad = PT_HAVE_ACCESSED_DIRTY(w);
@@ -411,6 +413,12 @@ static int FNAME(walk_addr_generic)(struct guest_walker *walker,
if (unlikely(kvm_is_error_hva(host_addr)))
goto error;
+ if (!kvm_mem_attributes_may_read_gfn(vcpu->kvm, gpa_to_gfn(real_gpa))) {
+ walker->memory_attributes_fault = true;
+ walker->gfn = gpa_to_gfn(real_gpa);
+ goto error;
+ }
+
ptep_user = (pt_element_t __user *)((void *)host_addr + offset);
if (unlikely(get_user(pte, ptep_user)))
goto error;
@@ -820,6 +828,12 @@ static int FNAME(page_fault)(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault
* The page is not mapped by the guest. Let the guest handle it.
*/
if (!r) {
+ if (walker.memory_attributes_fault) {
+ fault->gfn = walker.gfn;
+ kvm_mmu_prepare_memory_fault_exit(vcpu, fault);
+ return -EFAULT;
+ }
+
if (!fault->prefetch)
__kvm_inject_emulated_page_fault(vcpu, &walker.fault, true);
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* Re: [PATCH v2 22/28] KVM: x86/mmu: Issue memory fault exit if walk failed due to memory attribute
2026-09-18 8:15 ` [PATCH v2 22/28] KVM: x86/mmu: Issue memory fault exit if walk failed due to memory attribute Paolo Bonzini
@ 2026-09-18 8:37 ` sashiko-bot
0 siblings, 0 replies; 44+ messages in thread
From: sashiko-bot @ 2026-09-18 8:37 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: kvm
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] kvm: KVM_EXIT_MEMORY_FAULT reports original access type instead of PTE read
- [High] kvm: memory attribute violations during emulation inject spurious #PF
--
commit f13a0662fba26c69b7ab24d7639e44c8da7ee24c
Author: Nicolas Saenz Julienne <nsaenz@amazon.com>
KVM: x86/mmu: Issue memory fault exit if walk failed due to memory attribute
This patch adds a check during guest page table walks to identify if a walk
fails due to a memory attribute restriction. When this occurs, it populates
the newly added memory_attributes_fault flag and attempts to exit to userspace
with a memory fault.
> diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h
> index b031123fcb369..d2836a327bc99 100644
> --- a/arch/x86/kvm/mmu/paging_tmpl.h
> +++ b/arch/x86/kvm/mmu/paging_tmpl.h
[ ... ]
> @@ -411,6 +413,12 @@ static int FNAME(walk_addr_generic)(struct guest_walker *walker,
> if (unlikely(kvm_is_error_hva(host_addr)))
> goto error;
>
> + if (!kvm_mem_attributes_may_read_gfn(vcpu->kvm, gpa_to_gfn(real_gpa))) {
> + walker->memory_attributes_fault = true;
> + walker->gfn = gpa_to_gfn(real_gpa);
> + goto error;
> + }
> +
[Severity: High]
When this flag is set and FNAME(walk_addr_generic)() returns an error, how is
it handled by other callers that aren't updated in this patch?
For example, in arch/x86/kvm/mmu/paging_tmpl.h within FNAME(gva_to_gpa)():
static gpa_t FNAME(gva_to_gpa)(struct kvm_vcpu *vcpu, struct kvm_pagewalk *w,
gpa_t addr, u64 access,
struct x86_exception *exception)
{
struct guest_walker walker;
gpa_t gpa = INVALID_GPA;
int r;
r = FNAME(walk_addr_generic)(&walker, vcpu, w, addr, access);
if (r) {
gpa = gfn_to_gpa(walker.gfn);
gpa |= addr & ~PAGE_MASK;
} else if (exception)
*exception = walker.fault;
If instruction emulation encounters a memory attribute violation here during a
page table walk, does this drop the walker.memory_attributes_fault flag and
blindly return the fabricated #PF exception?
Could this inject a spurious #PF into the guest instead of exiting to userspace
with KVM_EXIT_MEMORY_FAULT?
[ ... ]
> @@ -820,6 +828,12 @@ static int FNAME(page_fault)(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault
> * The page is not mapped by the guest. Let the guest handle it.
> */
> if (!r) {
> + if (walker.memory_attributes_fault) {
> + fault->gfn = walker.gfn;
> + kvm_mmu_prepare_memory_fault_exit(vcpu, fault);
> + return -EFAULT;
> + }
> +
[Severity: High]
In arch/x86/kvm/mmu/paging_tmpl.h within FNAME(page_fault)(), if
walker.memory_attributes_fault is true, we prepare a memory fault exit.
However, does kvm_mmu_prepare_memory_fault_exit() use the original fault's
properties (fault->write, fault->exec) instead of the properties of the page
table read itself?
Could this incorrectly report the access flags to userspace (e.g., reporting
WRITE or EXEC instead of READ) when a page table walk fails due to KVM memory
attributes?
> if (!fault->prefetch)
> __kvm_inject_emulated_page_fault(vcpu, &walker.fault, true);
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918081543.139871-1-pbonzini@redhat.com?part=22
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v2 23/28] KVM: x86/mmu: Do not update accessed/dirty if guest PTE is read-only
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
` (21 preceding siblings ...)
2026-09-18 8:15 ` [PATCH v2 22/28] KVM: x86/mmu: Issue memory fault exit if walk failed due to memory attribute Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:15 ` [PATCH v2 24/28] KVM: x86/mmu: Do not prefetch sptes on gfns backed by memory attributes Paolo Bonzini
` (4 subsequent siblings)
27 siblings, 0 replies; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
From: Nicolas Saenz Julienne <nsaenz@amazon.com>
In this case do not go all the way out to userspace and just stomp out
the write. This is consistent with the way KVM handles read-only
memory slots during emulation, though admittedly inconsistent with
everything else: NPT for example always wants nested page table entries
for the guest page tables to be writable, and will fault.
Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/kvm/mmu/paging_tmpl.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h
index d2836a327bc9..2ff655edd57c 100644
--- a/arch/x86/kvm/mmu/paging_tmpl.h
+++ b/arch/x86/kvm/mmu/paging_tmpl.h
@@ -419,6 +419,9 @@ static int FNAME(walk_addr_generic)(struct guest_walker *walker,
goto error;
}
+ if (!kvm_mem_attributes_may_write_gfn(vcpu->kvm, gpa_to_gfn(real_gpa)))
+ walker->pte_writable[walker->level - 1] = false;
+
ptep_user = (pt_element_t __user *)((void *)host_addr + offset);
if (unlikely(get_user(pte, ptep_user)))
goto error;
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v2 24/28] KVM: x86/mmu: Do not prefetch sptes on gfns backed by memory attributes
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
` (22 preceding siblings ...)
2026-09-18 8:15 ` [PATCH v2 23/28] KVM: x86/mmu: Do not update accessed/dirty if guest PTE is read-only Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:36 ` sashiko-bot
2026-09-18 8:15 ` [PATCH v2 25/28] KVM: x86/mmu: Obsolete all roots if memattr contains gPTEs Paolo Bonzini
` (3 subsequent siblings)
27 siblings, 1 reply; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
From: Nicolas Saenz Julienne <nsaenz@amazon.com>
Prefetched SPTEs are always given full access. Do not prefetch GFNs
that have memory protections applied.
Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/kvm/mmu/mmu.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 3fd4cc3c57a5..097095f71d60 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -3187,6 +3187,11 @@ static bool kvm_mmu_prefetch_sptes(struct kvm_vcpu *vcpu, gfn_t gfn, u64 *sptep,
return false;
for (i = 0; i < nr_pages; i++, gfn++, sptep++) {
+ if (!kvm_get_memory_attributes(vcpu->kvm, gfn)) {
+ kvm_release_page_clean(pages[i]);
+ continue;
+ }
+
mmu_set_spte(vcpu, slot, sptep, access, gfn,
page_to_pfn(pages[i]), NULL);
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* Re: [PATCH v2 24/28] KVM: x86/mmu: Do not prefetch sptes on gfns backed by memory attributes
2026-09-18 8:15 ` [PATCH v2 24/28] KVM: x86/mmu: Do not prefetch sptes on gfns backed by memory attributes Paolo Bonzini
@ 2026-09-18 8:36 ` sashiko-bot
0 siblings, 0 replies; 44+ messages in thread
From: sashiko-bot @ 2026-09-18 8:36 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: kvm
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] kvm: x86/mmu: inverted condition in kvm_mmu_prefetch_sptes() bypasses memory protections
--
commit 68c32d2a3026b65b5bee3d2be8dae5b6311d03d5
Author: Nicolas Saenz Julienne <nsaenz@amazon.com>
KVM: x86/mmu: Do not prefetch sptes on gfns backed by memory attributes
This commit aims to prevent prefetching GFNs that have memory protections
applied, because prefetched SPTEs are always given full access. It
introduces a check using kvm_get_memory_attributes() to skip prefetching
for such pages.
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 3fd4cc3c57a53..097095f71d605 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -3187,6 +3187,11 @@ static bool kvm_mmu_prefetch_sptes(struct kvm_vcpu *vcpu, gfn_t gfn, u64 *sptep,
> return false;
>
> for (i = 0; i < nr_pages; i++, gfn++, sptep++) {
> + if (!kvm_get_memory_attributes(vcpu->kvm, gfn)) {
> + kvm_release_page_clean(pages[i]);
> + continue;
> + }
[Severity: High]
Does this logic invert the intended check?
When a page has no memory attributes, kvm_get_memory_attributes() returns 0,
making the ! condition evaluate to true. This causes normal memory pages to
be skipped, which could lead to performance regressions.
Conversely, if a page does have memory attributes, it returns non-zero, making
the condition false. Could an untrusted guest VM deterministically trigger
page prefetching by faulting on adjacent pages, allowing protected memory
to fall through to mmu_set_spte() and be mapped with full access?
> +
> mmu_set_spte(vcpu, slot, sptep, access, gfn,
> page_to_pfn(pages[i]), NULL);
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918081543.139871-1-pbonzini@redhat.com?part=24
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v2 25/28] KVM: x86/mmu: Obsolete all roots if memattr contains gPTEs
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
` (23 preceding siblings ...)
2026-09-18 8:15 ` [PATCH v2 24/28] KVM: x86/mmu: Do not prefetch sptes on gfns backed by memory attributes Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:43 ` sashiko-bot
2026-09-18 8:15 ` [PATCH v2 26/28] KVM: x86: selftests: Introduce memory protection attributes test Paolo Bonzini
` (2 subsequent siblings)
27 siblings, 1 reply; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
Note that the zapping of obsolete roots needs to happen after
mmu_lock is dropped, so introduce a separate kvm_arch callback.
The two map neatly to the "front" and "back" halves of
kvm_mmu_zap_all_fast().
Co-developed-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/kvm/mmu/mmu.c | 32 ++++++++++++++++++++++++++++++++
include/linux/kvm_host.h | 1 +
virt/kvm/kvm_main.c | 7 +++++--
3 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 097095f71d60..d658cfe31cd9 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -8265,6 +8265,7 @@ bool kvm_arch_post_set_memory_attributes(struct kvm *kvm,
{
unsigned long attrs = range->arg.attributes;
struct kvm_memory_slot *slot = range->slot;
+ struct kvm_mmu_page *sp;
int level;
lockdep_assert_held_write(&kvm->mmu_lock);
@@ -8320,9 +8321,40 @@ bool kvm_arch_post_set_memory_attributes(struct kvm *kvm,
hugepage_set_mixed(slot, gfn, level);
}
}
+
+ /*
+ * There are special considerations when applying an memory protection
+ * attibute against a GPTE page. If set read-only, access/dirty bits
+ * within that page shouldn't be updated. If set non-accesible,
+ * accessing a virtual address that requires traversing that GPTE page
+ * should fault.
+ *
+ * On TDP enabled guests, the CPU faults on the GPTE address upon
+ * detecting such a situation.
+ *
+ * On non-TDP, upon detecting this situation, and based on the fact it
+ * should be a rare occasion, invalidate all the mmu roots.
+ */
+ for (gfn_t gfn = range->start; gfn < range->end; gfn++) {
+ for_each_gfn_valid_sp_with_gptes(kvm, sp, gfn) {
+ __kvm_mmu_zap_all_fast_front_half(kvm);
+ return false;
+ }
+ }
return false;
}
+void kvm_arch_post_set_memory_attributes_unlocked(struct kvm *kvm)
+{
+ /*
+ * This may also be called if no zap was done in
+ * kvm_arch_post_set_memory_attributes(). It is not an issue because
+ * __kvm_mmu_zap_all_fast_back_half() is cheap when it does not do
+ * anything.
+ */
+ __kvm_mmu_zap_all_fast_back_half(kvm);
+}
+
void kvm_mmu_init_memslot_memory_attributes(struct kvm *kvm,
struct kvm_memory_slot *slot)
{
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index e9c0932f150e..33f3199a855f 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -2624,6 +2624,7 @@ bool kvm_arch_pre_set_memory_attributes(struct kvm *kvm,
struct kvm_gfn_range *range);
bool kvm_arch_post_set_memory_attributes(struct kvm *kvm,
struct kvm_gfn_range *range);
+void kvm_arch_post_set_memory_attributes_unlocked(struct kvm *kvm);
bool kvm_mem_attributes_valid(struct kvm *kvm, unsigned long attrs);
u64 kvm_supported_mem_attributes(struct kvm *kvm);
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 24f46dce192e..ccbec4796e4b 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2516,7 +2516,7 @@ static bool kvm_range_memory_attributes_need_sync(struct kvm *kvm,
return kvm_range_has_any_memory_attributes(kvm, start, end, mask);
}
-static __always_inline void kvm_handle_gfn_range(struct kvm *kvm,
+static __always_inline bool kvm_handle_gfn_range(struct kvm *kvm,
struct kvm_mmu_notifier_range *range)
{
struct kvm_gfn_range gfn_range;
@@ -2566,6 +2566,8 @@ static __always_inline void kvm_handle_gfn_range(struct kvm *kvm,
if (found_memslot)
KVM_MMU_UNLOCK(kvm);
+
+ return found_memslot;
}
static bool kvm_pre_set_memory_attributes(struct kvm *kvm,
@@ -2652,7 +2654,8 @@ static int kvm_vm_set_mem_attributes(struct kvm *kvm, gfn_t start, gfn_t end,
smp_store_release(&kvm->mem_attrs.generation,
kvm->mem_attrs.generation + 1);
- kvm_handle_gfn_range(kvm, &post_set_range);
+ if (kvm_handle_gfn_range(kvm, &post_set_range))
+ kvm_arch_post_set_memory_attributes_unlocked(kvm);
out_unlock:
mutex_unlock(&kvm->slots_lock);
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* Re: [PATCH v2 25/28] KVM: x86/mmu: Obsolete all roots if memattr contains gPTEs
2026-09-18 8:15 ` [PATCH v2 25/28] KVM: x86/mmu: Obsolete all roots if memattr contains gPTEs Paolo Bonzini
@ 2026-09-18 8:43 ` sashiko-bot
0 siblings, 0 replies; 44+ messages in thread
From: sashiko-bot @ 2026-09-18 8:43 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: kvm
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] kvm: mixed-attribute hugepage mapping via race when mmu_lock is dropped
- [High] kvm: soft lockup in kvm_arch_post_set_memory_attributes() due to unbounded loop
--
commit 33f579fe7310efff8ad87a283b4a1e970511e847
Author: Paolo Bonzini <pbonzini@redhat.com>
Subject: KVM: x86/mmu: Obsolete all roots if memattr contains gPTEs
This commit introduces a mechanism to invalidate all MMU roots when applying
memory protection attributes against a GPTE page. It splits the fast zap
operation into a locked front-half and an unlocked back-half.
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 097095f71d605..d658cfe31cd9b 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
[ ... ]
> @@ -8320,9 +8321,40 @@ bool kvm_arch_post_set_memory_attributes(struct kvm *kvm,
> hugepage_set_mixed(slot, gfn, level);
> }
> }
> +
> + /*
> + * There are special considerations when applying an memory protection
> + * attibute against a GPTE page. If set read-only, access/dirty bits
> + * within that page shouldn't be updated. If set non-accesible,
> + * accessing a virtual address that requires traversing that GPTE page
> + * should fault.
> + *
> + * On TDP enabled guests, the CPU faults on the GPTE address upon
> + * detecting such a situation.
> + *
> + * On non-TDP, upon detecting this situation, and based on the fact it
> + * should be a rare occasion, invalidate all the mmu roots.
> + */
> + for (gfn_t gfn = range->start; gfn < range->end; gfn++) {
[Severity: High]
Could this loop cause a host soft lockup and RCU stalls?
If host userspace issues a KVM_SET_MEMORY_ATTRIBUTES ioctl with a massive
memory range, this loop will iterate over the entire guest-controlled GFN
range.
Because it executes hash table lookups via for_each_gfn_valid_sp_with_gptes()
while holding mmu_lock for write without any cond_resched(), could a
malicious guest or VMM orchestrate massive memslot updates to degrade host
availability?
> + for_each_gfn_valid_sp_with_gptes(kvm, sp, gfn) {
> + __kvm_mmu_zap_all_fast_front_half(kvm);
[Severity: Critical]
Can this lead to memory isolation breakage by allowing mixed-attribute
hugepage mappings?
During kvm_vm_set_mem_attributes(), kvm_handle_gfn_range() is called with
post_set_range. When processing the first memslot, it triggers range->on_lock,
which maps to kvm_mmu_invalidate_end() and sets mmu_invalidate_in_progress
to 0.
When __kvm_mmu_zap_all_fast_front_half() is called here, it can drop and
reacquire mmu_lock via cond_resched_rwlock_write().
While the lock is dropped and mmu_invalidate_in_progress is 0, could a
concurrent page fault on a subsequent memslot proceed? If that memslot's
disallow_lpage flag hasn't been updated yet, KVM might map a hugepage using
the specific faulted GFN's attributes, bypassing the mixed attributes in the
xarray entirely.
> + return false;
> + }
> + }
> return false;
> }
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918081543.139871-1-pbonzini@redhat.com?part=25
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v2 26/28] KVM: x86: selftests: Introduce memory protection attributes test
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
` (24 preceding siblings ...)
2026-09-18 8:15 ` [PATCH v2 25/28] KVM: x86/mmu: Obsolete all roots if memattr contains gPTEs Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:39 ` sashiko-bot
2026-09-18 8:15 ` [PATCH v2 27/28] KVM: x86: selftests: Introduce memory attributes PTE test Paolo Bonzini
2026-09-18 8:15 ` [PATCH v2 28/28] KVM: x86: selftests: Introduce memory attributes side-channel tests Paolo Bonzini
27 siblings, 1 reply; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
Introduce architecture-independent tests for memory attributes, using
small architecture-specific snippets to handle the execution tests.
Co-developed-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
tools/include/uapi/linux/kvm.h | 3 +
tools/testing/selftests/kvm/Makefile.kvm | 1 +
.../testing/selftests/kvm/include/kvm_util.h | 23 +-
.../testing/selftests/kvm/memory_attributes.c | 373 ++++++++++++++++++
.../selftests/kvm/x86/memory_attributes.c | 43 ++
5 files changed, 433 insertions(+), 10 deletions(-)
create mode 100644 tools/testing/selftests/kvm/memory_attributes.c
create mode 100644 tools/testing/selftests/kvm/x86/memory_attributes.c
diff --git a/tools/include/uapi/linux/kvm.h b/tools/include/uapi/linux/kvm.h
index 419011097fa8..9bd6488adc62 100644
--- a/tools/include/uapi/linux/kvm.h
+++ b/tools/include/uapi/linux/kvm.h
@@ -1649,6 +1649,9 @@ struct kvm_memory_attributes {
__u64 flags;
};
+#define KVM_MEMORY_ATTRIBUTE_NR (1ULL << 0)
+#define KVM_MEMORY_ATTRIBUTE_NW (1ULL << 1)
+#define KVM_MEMORY_ATTRIBUTE_NX (1ULL << 2)
#define KVM_MEMORY_ATTRIBUTE_PRIVATE (1ULL << 3)
#define KVM_CREATE_GUEST_MEMFD _IOWR(KVMIO, 0xd4, struct kvm_create_guest_memfd)
diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm
index 6e2bbf743eaa..776b91c800d0 100644
--- a/tools/testing/selftests/kvm/Makefile.kvm
+++ b/tools/testing/selftests/kvm/Makefile.kvm
@@ -167,6 +167,7 @@ TEST_GEN_PROGS_x86 += rseq_test
TEST_GEN_PROGS_x86 += steal_time
TEST_GEN_PROGS_x86 += system_counter_offset_test
TEST_GEN_PROGS_x86 += pre_fault_memory_test
+TEST_GEN_PROGS_x86 += memory_attributes
# Compiled outputs used by test targets
TEST_GEN_PROGS_EXTENDED_x86 += x86/nx_huge_pages_test
diff --git a/tools/testing/selftests/kvm/include/kvm_util.h b/tools/testing/selftests/kvm/include/kvm_util.h
index 5a7a455b5387..996909230ac7 100644
--- a/tools/testing/selftests/kvm/include/kvm_util.h
+++ b/tools/testing/selftests/kvm/include/kvm_util.h
@@ -418,24 +418,27 @@ static inline void vm_enable_cap(struct kvm_vm *vm, u32 cap, u64 arg0)
vm_ioctl(vm, KVM_ENABLE_CAP, &enable_cap);
}
-static inline void vm_set_memory_attributes(struct kvm_vm *vm, gpa_t gpa,
- u64 size, u64 attributes)
+static inline int __vm_set_memory_attributes(struct kvm_vm *vm, u64 gpa,
+ u64 size, u64 attributes,
+ u64 flags)
{
struct kvm_memory_attributes attr = {
.attributes = attributes,
.address = gpa,
.size = size,
- .flags = 0,
+ .flags = flags,
};
- /*
- * KVM_SET_MEMORY_ATTRIBUTES overwrites _all_ attributes. These flows
- * need significant enhancements to support multiple attributes.
- */
- TEST_ASSERT(!attributes || attributes == KVM_MEMORY_ATTRIBUTE_PRIVATE,
- "Update me to support multiple attributes!");
+ return __vm_ioctl(vm, KVM_SET_MEMORY_ATTRIBUTES, &attr);
+}
- vm_ioctl(vm, KVM_SET_MEMORY_ATTRIBUTES, &attr);
+static inline void vm_set_memory_attributes(struct kvm_vm *vm, gpa_t gpa,
+ u64 size, u64 attributes)
+{
+ int rc;
+
+ rc = __vm_set_memory_attributes(vm, gpa, size, attributes, 0);
+ TEST_ASSERT_VM_VCPU_IOCTL(!rc, KVM_SET_MEMORY_ATTRIBUTES, rc, vm);
}
diff --git a/tools/testing/selftests/kvm/memory_attributes.c b/tools/testing/selftests/kvm/memory_attributes.c
new file mode 100644
index 000000000000..1e6e78f43100
--- /dev/null
+++ b/tools/testing/selftests/kvm/memory_attributes.c
@@ -0,0 +1,373 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2024, Amazon.com, Inc. or its affiliates. All Rights Reserved
+ *
+ * Test for KVM_MEMORY_ATTRIBUTES
+ */
+#include <pthread.h>
+#include <signal.h>
+
+#include "test_util.h"
+#include "ucall_common.h"
+#include "kvm_util.h"
+#include "processor.h"
+#include "hyperv.h"
+#include "apic.h"
+#include "asm/pvclock-abi.h"
+
+#define KVM_MEMORY_ATTRIBUTE_NO_ACCESS \
+ (KVM_MEMORY_ATTRIBUTE_NR | KVM_MEMORY_ATTRIBUTE_NW | \
+ KVM_MEMORY_ATTRIBUTE_NX)
+
+#define TEST_MEM_SLOT 1
+#define TEST_MEM_GPA 0x80000000
+
+#define MMIO_GPA 0x700000000
+#define MMIO_GVA MMIO_GPA
+
+enum {
+ TEST_OP_NOP,
+ TEST_OP_READ,
+ TEST_OP_WRITE,
+ TEST_OP_EXEC,
+ TEST_OP_EXIT,
+};
+
+const char *test_op_names[] =
+{
+ [TEST_OP_READ] = "Read",
+ [TEST_OP_WRITE] = "Write",
+ [TEST_OP_EXEC] = "Exec",
+ [TEST_OP_EXIT] = "Exit",
+};
+
+struct test_data {
+ uint8_t op;
+ int stage;
+ gva_t vaddr;
+
+ struct kvm_vcpu *vcpu;
+};
+
+static struct test_data *test_data;
+
+static uint64_t arch_controlled_read(gva_t addr);
+static void arch_controlled_write(gva_t addr, uint64_t val);
+static void arch_controlled_exec(gva_t addr);
+static void arch_write_return_insn(struct kvm_vm *vm, gpa_t vaddr);
+
+static void guest_code(void *data)
+{
+ struct test_data *test_data = data;
+ int stage = 1;
+
+ while (true) {
+ gva_t vaddr = READ_ONCE(test_data->vaddr);
+
+ switch(READ_ONCE(test_data->op)) {
+ case TEST_OP_READ:
+ (void) arch_controlled_read(vaddr);
+ GUEST_SYNC(stage++);
+ break;
+ case TEST_OP_WRITE:
+ arch_controlled_write(vaddr, 1);
+ GUEST_SYNC(stage++);
+ break;
+ case TEST_OP_EXEC:
+ arch_controlled_exec(vaddr);
+ GUEST_SYNC(stage++);
+ break;
+ default:
+ goto exit;
+ };
+ }
+
+exit:
+ GUEST_DONE();
+}
+
+static void vcpu_run_and_inc_stage(struct kvm_vcpu *vcpu)
+{
+ struct ucall uc;
+
+ vcpu_run(vcpu);
+
+ TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_IO);
+ switch (get_ucall(vcpu, &uc)) {
+ case UCALL_SYNC:
+ TEST_ASSERT(uc.args[1] == test_data->stage,
+ "Unexpected stage: %ld (%d expected)",
+ uc.args[1], test_data->stage);
+ break;
+ case UCALL_ABORT:
+ REPORT_GUEST_ASSERT(uc);
+ /* NOT REACHED */
+ default:
+ TEST_FAIL("Unknown ucall %lu", uc.cmd);
+ }
+
+ test_data->stage++;
+}
+
+static void test_page_restricted(struct kvm_vcpu *vcpu, int op,
+ gva_t vaddr, gpa_t fault_paddr,
+ uint64_t fault_reason)
+{
+ struct kvm_vm *vm = vcpu->vm;
+ int rc;
+
+ test_data->op = op;
+ test_data->vaddr = vaddr;
+
+ rc = _vcpu_run(vcpu);
+ TEST_ASSERT(rc == -1 && errno == EFAULT,
+ "KVM_RUN IOCTL didn't return EFAULT on %s, rc %d, errno %d",
+ test_op_names[op], rc, errno);
+ TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_MEMORY_FAULT);
+ TEST_ASSERT_EQ(vcpu->run->memory_fault.gpa, fault_paddr);
+ TEST_ASSERT_EQ(vcpu->run->memory_fault.flags, fault_reason);
+ TEST_ASSERT_EQ(vcpu->run->memory_fault.size, vm->page_size);
+}
+
+static void test_page_accessible(struct kvm_vcpu *vcpu, int op, gva_t vaddr)
+{
+ test_data->op = op;
+ test_data->vaddr = vaddr;
+ vcpu_run_and_inc_stage(vcpu);
+}
+
+#include "x86/memory_attributes.c"
+
+/*
+ * We want to test the following cases:
+ * - Sucessful access to GPAs backed by memory attributes (for ex. read access
+ * on an read-only page).
+ * - First fault after setting memory attributes, with unpopulated SPTEs/EPTS.
+ * - Fault caused by an SPTE/EPT reflecting the memory attributes.
+ *
+ * The list of ops below tests the 3 situations for each memory attribute
+ * combination.
+ */
+const struct memory_access {
+ const char *name;
+ uint64_t attrs;
+ int ops[5];
+} access_array[] = {
+ { "all allowed", 0, { TEST_OP_READ, TEST_OP_WRITE, TEST_OP_EXEC } },
+ { "no write (unmapped)", KVM_MEMORY_ATTRIBUTE_NW,
+ { TEST_OP_WRITE, TEST_OP_READ, TEST_OP_EXEC, TEST_OP_WRITE } },
+ { "no write (mapped)", KVM_MEMORY_ATTRIBUTE_NW,
+ { TEST_OP_READ, TEST_OP_WRITE, TEST_OP_READ, TEST_OP_EXEC, TEST_OP_WRITE } },
+ { "no exec (unmapped)", KVM_MEMORY_ATTRIBUTE_NX,
+ { TEST_OP_EXEC, TEST_OP_READ, TEST_OP_WRITE, TEST_OP_EXEC } },
+ { "no exec (mapped)", KVM_MEMORY_ATTRIBUTE_NX,
+ { TEST_OP_READ, TEST_OP_EXEC, TEST_OP_READ, TEST_OP_WRITE, TEST_OP_EXEC } },
+ { "read only", KVM_MEMORY_ATTRIBUTE_NW | KVM_MEMORY_ATTRIBUTE_NX,
+ { TEST_OP_EXEC, TEST_OP_WRITE, TEST_OP_READ, TEST_OP_WRITE,
+ TEST_OP_EXEC } },
+ { "no access (map on read)", KVM_MEMORY_ATTRIBUTE_NO_ACCESS,
+ { TEST_OP_READ, TEST_OP_WRITE, TEST_OP_EXEC } },
+ { "no access (map on write)", KVM_MEMORY_ATTRIBUTE_NO_ACCESS,
+ { TEST_OP_WRITE, TEST_OP_READ, TEST_OP_EXEC } },
+ { "no access (map on exec)", KVM_MEMORY_ATTRIBUTE_NO_ACCESS,
+ { TEST_OP_EXEC, TEST_OP_READ, TEST_OP_WRITE } },
+ /* Verify everything is back to normal */
+ { "all allowed (2)", 0, { TEST_OP_READ, TEST_OP_WRITE, TEST_OP_EXEC } },
+};
+
+static void test_page_access(struct kvm_vcpu *vcpu, gva_t vaddr,
+ uint64_t attrs, const int ops[])
+{
+ struct kvm_vm *vm = vcpu->vm;
+ gpa_t paddr = addr_gva2gpa(vm, vaddr);
+
+ for (int i = 0; i < ARRAY_SIZE(access_array[0].ops); i++) {
+ int op = ops[i];
+
+ if (op == TEST_OP_NOP)
+ continue;
+
+ /*
+ * We're about to have the guest jump into 'vaddr', make it a
+ * 'ret' instruction so it returns right away.
+ */
+ if (op == TEST_OP_EXEC)
+ arch_write_return_insn(vm, paddr);
+
+ vm_set_memory_attributes(vm, paddr, vm->page_size, attrs);
+
+ /*
+ * Attributes are negated, a match means the operation should
+ * fail.
+ */
+ if (attrs & BIT_ULL(op - 1)) {
+ test_page_restricted(vcpu, op, vaddr, paddr, BIT(op - 1));
+ vm_set_memory_attributes(vm, paddr, vm->page_size, 0);
+ }
+
+ test_page_accessible(vcpu, op, vaddr);
+ }
+
+}
+
+static void test_memory_access(struct kvm_vcpu *vcpu, gva_t test_vm_vaddr,
+ size_t size)
+{
+ struct kvm_vm *vm = vcpu->vm;
+ gpa_t test_vm_paddr = addr_gva2gpa(vm, test_vm_vaddr);
+
+ printf("gva %lx gpa %lx\n", test_vm_vaddr, test_vm_paddr);
+ for (size_t i = 0; i < ARRAY_SIZE(access_array); i++) {
+ uint64_t attrs = access_array[i].attrs;
+
+ printf("starting %s test...\n", access_array[i].name);
+ vm_set_memory_attributes(vm, test_vm_paddr, size, attrs);
+
+ for (gva_t vaddr = test_vm_vaddr;
+ vaddr < test_vm_vaddr + size; vaddr += PAGE_SIZE) {
+ test_page_access(vcpu, vaddr, attrs, access_array[i].ops);
+ }
+ }
+}
+
+static void test_memattrs_ignore_mmio(struct kvm_vcpu *vcpu)
+{
+ struct kvm_vm *vm = vcpu->vm;
+
+ vm_set_memory_attributes(vm, MMIO_GPA, vm->page_size,
+ KVM_MEMORY_ATTRIBUTE_NO_ACCESS);
+
+ test_data->op = TEST_OP_READ;
+ test_data->vaddr = MMIO_GVA;
+ vcpu_run(vcpu);
+ TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_MMIO);
+ TEST_ASSERT_EQ(vcpu->run->mmio.phys_addr, MMIO_GPA);
+ TEST_ASSERT_EQ(vcpu->run->mmio.is_write, 0);
+ TEST_ASSERT_EQ(vcpu->run->mmio.len, 8);
+ vcpu_run_and_inc_stage(vcpu);
+
+ test_data->op = TEST_OP_WRITE;
+ test_data->vaddr = MMIO_GVA;
+ vcpu_run(vcpu);
+ TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_MMIO);
+ TEST_ASSERT_EQ(vcpu->run->mmio.phys_addr, MMIO_GPA);
+ TEST_ASSERT_EQ(vcpu->run->mmio.is_write, 1);
+ TEST_ASSERT_EQ(vcpu->run->mmio.len, 8);
+ vcpu_run_and_inc_stage(vcpu);
+
+ vm_set_memory_attributes(vm, MMIO_GPA, vm->page_size, 0);
+}
+
+static void test_input_validation(struct kvm_vm *vm)
+{
+ uint64_t flags, gpa = 0, size = 0, attrs = 0;
+ int rc;
+
+ /* 'flags' is unsupported */
+ flags = BIT(0);
+ rc = __vm_set_memory_attributes(vm, gpa, size, attrs, flags);
+ TEST_ASSERT_VM_VCPU_IOCTL(rc == -1 && errno == EINVAL,
+ KVM_SET_MEMORY_ATTRIBUTES, rc, vm);
+
+ /* 'size' can't be 0 */
+ flags = 0;
+ rc = __vm_set_memory_attributes(vm, gpa, size, attrs, flags);
+ TEST_ASSERT_VM_VCPU_IOCTL(rc == -1 && errno == EINVAL,
+ KVM_SET_MEMORY_ATTRIBUTES, rc, vm);
+
+ /* 'gpa' shouldn't overflow */
+ gpa = 0ULL - vm->page_size;
+ size = vm->page_size;
+ rc = __vm_set_memory_attributes(vm, gpa, size, attrs, flags);
+ TEST_ASSERT_VM_VCPU_IOCTL(rc == -1 && errno == EINVAL,
+ KVM_SET_MEMORY_ATTRIBUTES, rc, vm);
+
+ /* 'gpa' should be page aligned */
+ gpa = 1;
+ rc = __vm_set_memory_attributes(vm, gpa, size, attrs, flags);
+ TEST_ASSERT_VM_VCPU_IOCTL(rc == -1 && errno == EINVAL,
+ KVM_SET_MEMORY_ATTRIBUTES, rc, vm);
+
+ /* 'size' should be page aligned */
+ gpa = 0;
+ size = 1;
+ rc = __vm_set_memory_attributes(vm, gpa, size, attrs, flags);
+ TEST_ASSERT_VM_VCPU_IOCTL(rc == -1 && errno == EINVAL,
+ KVM_SET_MEMORY_ATTRIBUTES, rc, vm);
+
+ /* exec mappings require read access */
+ size = vm->page_size;
+ attrs = KVM_MEMORY_ATTRIBUTE_NR | KVM_MEMORY_ATTRIBUTE_NW;
+ rc = __vm_set_memory_attributes(vm, gpa, size, attrs, flags);
+ TEST_ASSERT_VM_VCPU_IOCTL(rc == -1 && errno == EINVAL,
+ KVM_SET_MEMORY_ATTRIBUTES, rc, vm);
+
+ /* write mappings require read access */
+ size = vm->page_size;
+ attrs = KVM_MEMORY_ATTRIBUTE_NR | KVM_MEMORY_ATTRIBUTE_NX;
+ rc = __vm_set_memory_attributes(vm, gpa, size, attrs, flags);
+ TEST_ASSERT_VM_VCPU_IOCTL(rc == -1 && errno == EINVAL,
+ KVM_SET_MEMORY_ATTRIBUTES, rc, vm);
+
+ /* private mappings are incompatible with access restrictions */
+ attrs = KVM_MEMORY_ATTRIBUTE_NW | KVM_MEMORY_ATTRIBUTE_PRIVATE;
+ rc = __vm_set_memory_attributes(vm, gpa, size, attrs, flags);
+ TEST_ASSERT_VM_VCPU_IOCTL(rc == -1 && errno == EINVAL,
+ KVM_SET_MEMORY_ATTRIBUTES, rc, vm);
+}
+
+static void test_finalize(struct kvm_vcpu *vcpu)
+{
+ test_data->op = TEST_OP_EXIT;
+ vcpu_run(vcpu);
+ TEST_ASSERT_EQ(get_ucall(vcpu, NULL), UCALL_DONE);
+}
+
+static struct test_data *init_test_data(struct kvm_vcpu *vcpu)
+{
+ struct kvm_vm *vm = vcpu->vm;
+ gva_t test_data_vm_vaddr;
+
+ test_data_vm_vaddr = vm_alloc_page(vm);
+ vcpu_args_set(vcpu, 1, test_data_vm_vaddr);
+
+ test_data = addr_gva2hva(vm, test_data_vm_vaddr);
+ test_data->stage = 1;
+ test_data->vcpu = vcpu;
+
+ return test_data;
+}
+
+int main(int argc, char *argv[])
+{
+ uint32_t guest_page_size = vm_guest_mode_params[VM_MODE_DEFAULT].page_size;
+ unsigned int ptes_per_page = guest_page_size / 8;
+ size_t pages = ptes_per_page * 2; /* 2 huge-pages */
+ size_t size = guest_page_size * pages;
+ struct kvm_vcpu *vcpu;
+ gva_t test_mem;
+ struct kvm_vm *vm;
+
+ TEST_REQUIRE(kvm_check_cap(KVM_CAP_MEMORY_ATTRIBUTES) &
+ KVM_MEMORY_ATTRIBUTE_NO_ACCESS);
+
+ vm = __vm_create_with_one_vcpu(&vcpu, pages, guest_code);
+
+ /* add a few extra pages for use by tests */
+ vm_userspace_mem_region_add(vm, VM_MEM_SRC_ANONYMOUS,
+ TEST_MEM_GPA, TEST_MEM_SLOT,
+ pages + 100, 0);
+ vm->memslots[MEM_REGION_TEST_DATA] = TEST_MEM_SLOT;
+
+ test_mem = vm_alloc_pages(vm, pages);
+ virt_map(vcpu->vm, MMIO_GVA, MMIO_GPA, 1);
+ test_data = init_test_data(vcpu);
+
+ test_input_validation(vm);
+ test_memory_access(vcpu, test_mem, size);
+ test_memattrs_ignore_mmio(vcpu);
+ test_finalize(vcpu);
+
+ kvm_vm_free(vm);
+ return 0;
+}
diff --git a/tools/testing/selftests/kvm/x86/memory_attributes.c b/tools/testing/selftests/kvm/x86/memory_attributes.c
new file mode 100644
index 000000000000..2e1148f5146d
--- /dev/null
+++ b/tools/testing/selftests/kvm/x86/memory_attributes.c
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2024, Amazon.com, Inc. or its affiliates. All Rights Reserved
+ *
+ * Test for KVM_MEMORY_ATTRIBUTES
+ */
+#include "kvm_util.h"
+#include "apic.h"
+
+uint64_t arch_controlled_read(gva_t addr)
+{
+ uint64_t val;
+
+ asm volatile("mov %[addr], %%rax \n\r"
+ "mov (%%rax), %[val] \n\r"
+ : [val] "=r" (val)
+ : [addr] "m"(addr)
+ : "memory", "rax");
+
+ return val;
+}
+
+void arch_controlled_write(gva_t addr, uint64_t val)
+{
+ asm volatile("mov %[addr], %%rax \n\r"
+ "mov %[val], %%rbx \n\r"
+ "mov %%rbx, (%%rax) \n\r"
+ :: [addr] "m" (addr), [val] "m" (val)
+ : "memory", "rax", "rbx");
+}
+
+void arch_controlled_exec(gva_t addr)
+{
+ asm volatile("mov %[addr], %%rax \n\r"
+ "call *%%rax \n\t"
+ :: [addr] "m"(addr)
+ : "memory", "rax");
+}
+
+void arch_write_return_insn(struct kvm_vm *vm, gpa_t vaddr)
+{
+ memset(addr_gpa2hva(vm, vaddr), 0xc3, 1);
+}
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* Re: [PATCH v2 26/28] KVM: x86: selftests: Introduce memory protection attributes test
2026-09-18 8:15 ` [PATCH v2 26/28] KVM: x86: selftests: Introduce memory protection attributes test Paolo Bonzini
@ 2026-09-18 8:39 ` sashiko-bot
0 siblings, 0 replies; 44+ messages in thread
From: sashiko-bot @ 2026-09-18 8:39 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: kvm
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] selftests: incomplete capability check for KVM_MEMORY_ATTRIBUTE_NO_ACCESS
--
commit f041c4a018399e9454f5aa7f797e258a8a617f0e
Author: Paolo Bonzini <pbonzini@redhat.com>
KVM: x86: selftests: Introduce memory protection attributes test
This commit introduces architecture-independent tests for KVM memory
attributes, utilizing small architecture-specific snippets to handle
the execution tests.
> diff --git a/tools/testing/selftests/kvm/memory_attributes.c b/tools/testing/selftests/kvm/memory_attributes.c
> new file mode 100644
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/memory_attributes.c
[ ... ]
> +int main(int argc, char *argv[])
> +{
[ ... ]
> + struct kvm_vm *vm;
> +
> + TEST_REQUIRE(kvm_check_cap(KVM_CAP_MEMORY_ATTRIBUTES) &
> + KVM_MEMORY_ATTRIBUTE_NO_ACCESS);
[Severity: Medium]
Does this capability check in main() ensure that all required attributes are
supported?
Since KVM_MEMORY_ATTRIBUTE_NO_ACCESS is composed of multiple bits (NR, NW,
and NX), a bitwise AND evaluates to true even if the kernel only supports a
single subset attribute.
If only partial support is present, wouldn't the test proceed and
unconditionally iterate over access_array, where the ioctl to set
unsupported attributes fails with -EINVAL and triggers a TEST_ASSERT crash
instead of a graceful skip?
Could this be updated to verify that all bits in the mask are present?
> +
> + vm = __vm_create_with_one_vcpu(&vcpu, pages, guest_code);
> +
> + /* add a few extra pages for use by tests */
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918081543.139871-1-pbonzini@redhat.com?part=26
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v2 27/28] KVM: x86: selftests: Introduce memory attributes PTE test
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
` (25 preceding siblings ...)
2026-09-18 8:15 ` [PATCH v2 26/28] KVM: x86: selftests: Introduce memory protection attributes test Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:15 ` [PATCH v2 28/28] KVM: x86: selftests: Introduce memory attributes side-channel tests Paolo Bonzini
27 siblings, 0 replies; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
Add more memory attributes tests to check that memory protection
restricts accesses even when installed on a page that holds guest page
table entries. Notably two cases are taken into account:
- The page is made non-accesible. In such case the next access to a
virtual memory address translated by that paging structure should
fault.
- The page is made read-only. In such case the next access to a virtual
memory address translated by that paging structure should either fault,
or succeed yet not perform any writes into the PTE (accessed and
dirty bits).
Co-developed-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
.../testing/selftests/kvm/memory_attributes.c | 39 ++++-
.../selftests/kvm/x86/memory_attributes.c | 144 +++++++++++++++++-
2 files changed, 177 insertions(+), 6 deletions(-)
diff --git a/tools/testing/selftests/kvm/memory_attributes.c b/tools/testing/selftests/kvm/memory_attributes.c
index 1e6e78f43100..c703c5586d43 100644
--- a/tools/testing/selftests/kvm/memory_attributes.c
+++ b/tools/testing/selftests/kvm/memory_attributes.c
@@ -25,11 +25,16 @@
#define MMIO_GPA 0x700000000
#define MMIO_GVA MMIO_GPA
+#define PT_WRITABLE_MASK BIT_ULL(1)
+#define PT_ACCESSED_MASK BIT_ULL(5)
+#define PTE_VADDR 0x1000000000
+
enum {
TEST_OP_NOP,
TEST_OP_READ,
TEST_OP_WRITE,
TEST_OP_EXEC,
+ TEST_OP_INVPLG,
TEST_OP_EXIT,
};
@@ -38,6 +43,7 @@ const char *test_op_names[] =
[TEST_OP_READ] = "Read",
[TEST_OP_WRITE] = "Write",
[TEST_OP_EXEC] = "Exec",
+ [TEST_OP_INVPLG] = "Invplg",
[TEST_OP_EXIT] = "Exit",
};
@@ -45,6 +51,7 @@ struct test_data {
uint8_t op;
int stage;
gva_t vaddr;
+ uint64_t expected_val;
struct kvm_vcpu *vcpu;
};
@@ -54,7 +61,8 @@ static struct test_data *test_data;
static uint64_t arch_controlled_read(gva_t addr);
static void arch_controlled_write(gva_t addr, uint64_t val);
static void arch_controlled_exec(gva_t addr);
-static void arch_write_return_insn(struct kvm_vm *vm, gpa_t vaddr);
+static void arch_write_return_insn(struct kvm_vm *vm, gpa_t paddr);
+static bool arch_test_op(struct test_data *test_data);
static void guest_code(void *data)
{
@@ -62,6 +70,7 @@ static void guest_code(void *data)
int stage = 1;
while (true) {
+ uint64_t expected_val = READ_ONCE(test_data->expected_val);
gva_t vaddr = READ_ONCE(test_data->vaddr);
switch(READ_ONCE(test_data->op)) {
@@ -70,7 +79,7 @@ static void guest_code(void *data)
GUEST_SYNC(stage++);
break;
case TEST_OP_WRITE:
- arch_controlled_write(vaddr, 1);
+ arch_controlled_write(vaddr, expected_val);
GUEST_SYNC(stage++);
break;
case TEST_OP_EXEC:
@@ -78,7 +87,10 @@ static void guest_code(void *data)
GUEST_SYNC(stage++);
break;
default:
- goto exit;
+ if (!arch_test_op(test_data))
+ goto exit;
+ GUEST_SYNC(stage++);
+ break;
};
}
@@ -109,6 +121,21 @@ static void vcpu_run_and_inc_stage(struct kvm_vcpu *vcpu)
test_data->stage++;
}
+static int test_page(struct kvm_vcpu *vcpu, int op, gva_t vaddr)
+{
+ int rc;
+
+ test_data->op = op;
+ test_data->vaddr = vaddr;
+
+ rc = _vcpu_run(vcpu);
+
+ if (rc >= 0)
+ test_data->stage++;
+
+ return rc < 0 ? -errno : rc;
+}
+
static void test_page_restricted(struct kvm_vcpu *vcpu, int op,
gva_t vaddr, gpa_t fault_paddr,
uint64_t fault_reason)
@@ -125,7 +152,8 @@ static void test_page_restricted(struct kvm_vcpu *vcpu, int op,
test_op_names[op], rc, errno);
TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_MEMORY_FAULT);
TEST_ASSERT_EQ(vcpu->run->memory_fault.gpa, fault_paddr);
- TEST_ASSERT_EQ(vcpu->run->memory_fault.flags, fault_reason);
+ if (fault_reason)
+ TEST_ASSERT_EQ(vcpu->run->memory_fault.flags, fault_reason);
TEST_ASSERT_EQ(vcpu->run->memory_fault.size, vm->page_size);
}
@@ -366,6 +394,9 @@ int main(int argc, char *argv[])
test_input_validation(vm);
test_memory_access(vcpu, test_mem, size);
test_memattrs_ignore_mmio(vcpu);
+#ifdef __x86_64__
+ arch_test_memory_access_pte(vcpu, test_mem);
+#endif
test_finalize(vcpu);
kvm_vm_free(vm);
diff --git a/tools/testing/selftests/kvm/x86/memory_attributes.c b/tools/testing/selftests/kvm/x86/memory_attributes.c
index 2e1148f5146d..12395feb6ac7 100644
--- a/tools/testing/selftests/kvm/x86/memory_attributes.c
+++ b/tools/testing/selftests/kvm/x86/memory_attributes.c
@@ -37,7 +37,147 @@ void arch_controlled_exec(gva_t addr)
: "memory", "rax");
}
-void arch_write_return_insn(struct kvm_vm *vm, gpa_t vaddr)
+void arch_write_return_insn(struct kvm_vm *vm, gpa_t paddr)
{
- memset(addr_gpa2hva(vm, vaddr), 0xc3, 1);
+ memset(addr_gpa2hva(vm, paddr), 0xc3, 1);
+}
+
+bool arch_test_op(struct test_data *test_data)
+{
+ gva_t vaddr = READ_ONCE(test_data->vaddr);
+
+ switch(READ_ONCE(test_data->op)) {
+ case TEST_OP_INVPLG:
+ asm volatile("invlpg (%0)"
+ :: "b" (vaddr): "memory");
+ return true;
+ default:
+ return false;
+ }
+}
+
+/*
+ * This test validates that, during a page walk, if the page a PTE is placed in
+ * is read-only the accesss and dirty bits will not be written. Note There's a
+ * slight variation in behaviour between TDP and non-TDP VMs:
+ * - With TDP enabled, KVM issues a fault exit upon observing the non-writable
+ * page.
+ * - With non-TDP, the access bit is not set, but the walk succeeds.
+ *
+ * This is aligned with read-only memslots' behaviour.
+ */
+static void test_memory_access_pte_ro(struct kvm_vcpu *vcpu, gva_t vaddr)
+{
+ struct kvm_vm *vm = vcpu->vm;
+ gpa_t paddr;
+ u64 *pte;
+ const u64 accessed_mask = PTE_ACCESSED_MASK(&vm->mmu);
+
+ pte = vm_get_pte(vm, vaddr);
+ paddr = addr_hva2gpa(vm, pte) & GENMASK(61, vm->page_shift);
+
+ *pte &= ~accessed_mask;
+ vm_set_memory_attributes(vm, paddr, vm->page_size, KVM_MEMORY_ATTRIBUTE_NW);
+ if (test_page(vcpu, TEST_OP_READ, vaddr) < 0) {
+ test_page_restricted(vcpu, TEST_OP_READ, vaddr, paddr,
+ /* write PTE's accessed bit */
+ KVM_MEMORY_EXIT_FLAG_WRITE);
+
+ vm_set_memory_attributes(vm, paddr, vm->page_size, 0);
+ test_page_accessible(vcpu, TEST_OP_READ, vaddr);
+ TEST_ASSERT_EQ(*pte & accessed_mask, accessed_mask);
+
+ /* Re-run the test, now vaddr is backed by an EPT. */
+ *pte &= ~accessed_mask;
+ vm_set_memory_attributes(vm, paddr, vm->page_size,
+ KVM_MEMORY_ATTRIBUTE_NW);
+ test_page_restricted(vcpu, TEST_OP_READ, vaddr, paddr,
+ /* write PTE's accessed bit */
+ KVM_MEMORY_EXIT_FLAG_WRITE);
+ vm_set_memory_attributes(vm, paddr, vm->page_size, 0);
+ test_page_accessible(vcpu, TEST_OP_READ, vaddr);
+ } else {
+ TEST_ASSERT_EQ(*pte & accessed_mask, 0);
+ vm_set_memory_attributes(vm, paddr, vm->page_size, 0);
+ }
+}
+
+/*
+ * This test validates that, during a page walk, if the page a PTE is placed in
+ * is maked as non-accesible, KVM issues a fault exit.
+ */
+static void test_memory_access_pte_nr(struct kvm_vcpu *vcpu, gva_t vaddr)
+{
+ struct kvm_vm *vm = vcpu->vm;
+ gpa_t paddr;
+ uint64_t *pte;
+
+ pte = vm_get_pte(vm, vaddr);
+ paddr = addr_hva2gpa(vm, pte) & GENMASK(61, vm->page_shift);
+
+ vm_set_memory_attributes(vm, paddr, vm->page_size,
+ KVM_MEMORY_ATTRIBUTE_NO_ACCESS);
+
+ test_page_restricted(vcpu, TEST_OP_READ, vaddr, paddr, 0);
+
+ vm_set_memory_attributes(vm, paddr, vm->page_size, 0);
+ test_page_accessible(vcpu, TEST_OP_READ, vaddr);
+
+ /* Re-run the test, now vaddr is backed by an SPTE. */
+ vm_set_memory_attributes(vm, paddr, vm->page_size,
+ KVM_MEMORY_ATTRIBUTE_NO_ACCESS);
+ test_page_restricted(vcpu, TEST_OP_READ, vaddr, paddr, 0);
+ vm_set_memory_attributes(vm, paddr, vm->page_size, 0);
+ test_page_accessible(vcpu, TEST_OP_READ, vaddr);
+}
+
+static void test_memory_access_sync_spte(struct kvm_vcpu *vcpu, gva_t vaddr)
+{
+ struct kvm_vm *vm = vcpu->vm;
+ gpa_t paddr = addr_gva2gpa(vm, vaddr);
+ uint64_t *pte, old_pte, new_pte;
+
+ pte = vm_get_pte(vm, vaddr);
+ gpa_t pte_paddr = addr_hva2gpa(vm, pte);
+ gpa_t pte_page_paddr = pte_paddr & GENMASK(61, vm->page_shift);
+ int pte_offset = pte_paddr - pte_page_paddr;
+ virt_pg_map(vm, PTE_VADDR, pte_page_paddr);
+ old_pte = *pte;
+
+ /* Set vmaddr as non-executable */
+ vm_set_memory_attributes(vm, paddr, vm->page_size, KVM_MEMORY_ATTRIBUTE_NX);
+
+ /*
+ * Make sure SPTEs are populated as previous op might have destroyed
+ * them. We new have a non-executable SPTE.
+ */
+ test_page_accessible(vcpu, TEST_OP_READ, vaddr);
+
+ /*
+ * Update PTE, make it non-writable and flush TLBs to make sure we go
+ * through the sync_spte path. This should update the SPTE and make it
+ * read-only.
+ */
+ new_pte = (old_pte & ~PT_WRITABLE_MASK) | PT_ACCESSED_MASK;
+ test_data->expected_val = new_pte;
+ test_page_accessible(vcpu, TEST_OP_WRITE, PTE_VADDR + pte_offset);
+ TEST_ASSERT_EQ(*pte, new_pte);
+ test_page_accessible(vcpu, TEST_OP_INVPLG, vaddr);
+
+ /* The not executable attrs remain valid */
+ arch_write_return_insn(vm, paddr);
+ test_page_restricted(vcpu, TEST_OP_EXEC, vaddr, paddr,
+ KVM_MEMORY_EXIT_FLAG_EXEC);
+
+ /* Cleanup */
+ *pte = old_pte;
+ vm_set_memory_attributes(vm, paddr, vm->page_size, 0);
+ test_page_accessible(vcpu, TEST_OP_EXEC, vaddr);
+}
+
+static void arch_test_memory_access_pte(struct kvm_vcpu *vcpu, gva_t vaddr)
+{
+ test_memory_access_pte_nr(vcpu, vaddr);
+ test_memory_access_pte_ro(vcpu, vaddr);
+ test_memory_access_sync_spte(vcpu, vaddr);
}
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v2 28/28] KVM: x86: selftests: Introduce memory attributes side-channel tests
2026-09-18 8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
` (26 preceding siblings ...)
2026-09-18 8:15 ` [PATCH v2 27/28] KVM: x86: selftests: Introduce memory attributes PTE test Paolo Bonzini
@ 2026-09-18 8:15 ` Paolo Bonzini
2026-09-18 8:43 ` sashiko-bot
27 siblings, 1 reply; 44+ messages in thread
From: Paolo Bonzini @ 2026-09-18 8:15 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: nsaenz, vkuznets, snambakam
Introduce memory attributes selftests to catch any vulnerable
side-channels.
Memory attributes access restrictions are vulnerable to side-channel
attacks. This means that any KVM operation initiated by the guest that
requires guest memory access (which is the case for most
para-virtualised interfaces) needs to consider memory attributes.
The tests confirm this requirement is upheld for a variety of
use-cases, exercising various kinds of guest memory access such as
kvm_read/write_guest(), gfn_to_hva_cache and gfn_to_pfn_cache.
Co-developed-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
.../testing/selftests/kvm/include/kvm_util.h | 9 +
.../selftests/kvm/include/x86/processor.h | 1 +
.../testing/selftests/kvm/lib/x86/processor.c | 5 +
.../testing/selftests/kvm/memory_attributes.c | 51 +++-
.../selftests/kvm/x86/memory_attributes.c | 232 ++++++++++++++++++
5 files changed, 297 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/kvm/include/kvm_util.h b/tools/testing/selftests/kvm/include/kvm_util.h
index 996909230ac7..b18af4f5f615 100644
--- a/tools/testing/selftests/kvm/include/kvm_util.h
+++ b/tools/testing/selftests/kvm/include/kvm_util.h
@@ -883,6 +883,15 @@ static inline int vcpu_get_stats_fd(struct kvm_vcpu *vcpu)
return fd;
}
+static inline struct kvm_translation vcpu_translate(struct kvm_vcpu *vcpu,
+ u64 gva)
+{
+ struct kvm_translation tr = { .linear_address = gva };
+
+ vcpu_ioctl(vcpu, KVM_TRANSLATE, &tr);
+ return tr;
+}
+
int __kvm_has_device_attr(int dev_fd, u32 group, u64 attr);
static inline void kvm_has_device_attr(int dev_fd, u32 group, u64 attr)
diff --git a/tools/testing/selftests/kvm/include/x86/processor.h b/tools/testing/selftests/kvm/include/x86/processor.h
index 6e6f70035508..398380157fa1 100644
--- a/tools/testing/selftests/kvm/include/x86/processor.h
+++ b/tools/testing/selftests/kvm/include/x86/processor.h
@@ -1472,6 +1472,7 @@ static inline bool kvm_is_lbrv_enabled(void)
return !!get_kvm_amd_param_integer("lbrv");
}
+u64 *vm_get_pte_level(struct kvm_vm *vm, gva_t gva, int *level);
u64 *vm_get_pte(struct kvm_vm *vm, gva_t gva);
u64 kvm_hypercall(u64 nr, u64 a0, u64 a1, u64 a2, u64 a3);
diff --git a/tools/testing/selftests/kvm/lib/x86/processor.c b/tools/testing/selftests/kvm/lib/x86/processor.c
index d31fa81ea075..f51b4929d668 100644
--- a/tools/testing/selftests/kvm/lib/x86/processor.c
+++ b/tools/testing/selftests/kvm/lib/x86/processor.c
@@ -400,6 +400,11 @@ u64 *tdp_get_pte(struct kvm_vm *vm, u64 l2_gpa)
return __vm_get_page_table_entry(vm, &vm->stage2_mmu, l2_gpa, &level);
}
+u64 *vm_get_pte_level(struct kvm_vm *vm, gva_t gva, int *level)
+{
+ return __vm_get_page_table_entry(vm, &vm->mmu, gva, level);
+}
+
u64 *vm_get_pte(struct kvm_vm *vm, gva_t gva)
{
int level = PG_LEVEL_4K;
diff --git a/tools/testing/selftests/kvm/memory_attributes.c b/tools/testing/selftests/kvm/memory_attributes.c
index c703c5586d43..63dec49c2888 100644
--- a/tools/testing/selftests/kvm/memory_attributes.c
+++ b/tools/testing/selftests/kvm/memory_attributes.c
@@ -22,6 +22,8 @@
#define TEST_MEM_SLOT 1
#define TEST_MEM_GPA 0x80000000
+#define HV_STATUS_INVALID_HYPERCALL_INPUT 3
+
#define MMIO_GPA 0x700000000
#define MMIO_GVA MMIO_GPA
@@ -29,12 +31,35 @@
#define PT_ACCESSED_MASK BIT_ULL(5)
#define PTE_VADDR 0x1000000000
+static volatile uint64_t ipis_rcvd;
+
+static pthread_t vcpu_thread;
+
+struct hv_vpset {
+ u64 format;
+ u64 valid_bank_mask;
+ u64 bank_contents[2];
+};
+
+enum HV_GENERIC_SET_FORMAT {
+ HV_GENERIC_SET_SPARSE_4K,
+ HV_GENERIC_SET_ALL,
+};
+
+struct hv_send_ipi_ex {
+ u32 vector;
+ u32 reserved;
+ struct hv_vpset vp_set;
+};
+
enum {
TEST_OP_NOP,
TEST_OP_READ,
TEST_OP_WRITE,
TEST_OP_EXEC,
TEST_OP_INVPLG,
+ TEST_OP_HYPERV_HYPERCALL_INPUT,
+ TEST_OP_MONITOR_ADDRESS,
TEST_OP_EXIT,
};
@@ -44,6 +69,8 @@ const char *test_op_names[] =
[TEST_OP_WRITE] = "Write",
[TEST_OP_EXEC] = "Exec",
[TEST_OP_INVPLG] = "Invplg",
+ [TEST_OP_HYPERV_HYPERCALL_INPUT] = "HvHcall input",
+ [TEST_OP_MONITOR_ADDRESS] = "Monitor address",
[TEST_OP_EXIT] = "Exit",
};
@@ -51,6 +78,8 @@ struct test_data {
uint8_t op;
int stage;
gva_t vaddr;
+ gpa_t paddr;
+ uint8_t confirm_read;
uint64_t expected_val;
struct kvm_vcpu *vcpu;
@@ -63,19 +92,26 @@ static void arch_controlled_write(gva_t addr, uint64_t val);
static void arch_controlled_exec(gva_t addr);
static void arch_write_return_insn(struct kvm_vm *vm, gpa_t paddr);
static bool arch_test_op(struct test_data *test_data);
+static void arch_guest_init(void);
static void guest_code(void *data)
{
struct test_data *test_data = data;
int stage = 1;
+ arch_guest_init();
+
while (true) {
uint64_t expected_val = READ_ONCE(test_data->expected_val);
+ bool confirm_read = READ_ONCE(test_data->confirm_read);
gva_t vaddr = READ_ONCE(test_data->vaddr);
+ u64 val;
switch(READ_ONCE(test_data->op)) {
case TEST_OP_READ:
- (void) arch_controlled_read(vaddr);
+ val = arch_controlled_read(vaddr);
+ if (confirm_read)
+ GUEST_ASSERT_EQ(expected_val, val);
GUEST_SYNC(stage++);
break;
case TEST_OP_WRITE:
@@ -86,6 +122,14 @@ static void guest_code(void *data)
arch_controlled_exec(vaddr);
GUEST_SYNC(stage++);
break;
+ case TEST_OP_MONITOR_ADDRESS: {
+ if (arch_controlled_read(vaddr) != expected_val)
+ GUEST_SYNC(stage++);
+ break;
+ }
+ case TEST_OP_NOP:
+ GUEST_SYNC(stage++);
+ break;
default:
if (!arch_test_op(test_data))
goto exit;
@@ -145,6 +189,7 @@ static void test_page_restricted(struct kvm_vcpu *vcpu, int op,
test_data->op = op;
test_data->vaddr = vaddr;
+ test_data->paddr = fault_paddr;
rc = _vcpu_run(vcpu);
TEST_ASSERT(rc == -1 && errno == EFAULT,
@@ -390,12 +435,16 @@ int main(int argc, char *argv[])
test_mem = vm_alloc_pages(vm, pages);
virt_map(vcpu->vm, MMIO_GVA, MMIO_GPA, 1);
test_data = init_test_data(vcpu);
+#ifdef __x86_64__
+ vcpu_set_hv_cpuid(vcpu);
+#endif
test_input_validation(vm);
test_memory_access(vcpu, test_mem, size);
test_memattrs_ignore_mmio(vcpu);
#ifdef __x86_64__
arch_test_memory_access_pte(vcpu, test_mem);
+ arch_test_side_channels(vcpu, test_mem, size);
#endif
test_finalize(vcpu);
diff --git a/tools/testing/selftests/kvm/x86/memory_attributes.c b/tools/testing/selftests/kvm/x86/memory_attributes.c
index 12395feb6ac7..6ce7da5cb376 100644
--- a/tools/testing/selftests/kvm/x86/memory_attributes.c
+++ b/tools/testing/selftests/kvm/x86/memory_attributes.c
@@ -45,17 +45,28 @@ void arch_write_return_insn(struct kvm_vm *vm, gpa_t paddr)
bool arch_test_op(struct test_data *test_data)
{
gva_t vaddr = READ_ONCE(test_data->vaddr);
+ gpa_t paddr = READ_ONCE(test_data->paddr);
switch(READ_ONCE(test_data->op)) {
case TEST_OP_INVPLG:
asm volatile("invlpg (%0)"
:: "b" (vaddr): "memory");
return true;
+ case TEST_OP_HYPERV_HYPERCALL_INPUT:
+ hyperv_hypercall(HVCALL_SEND_IPI_EX, paddr, 0);
+ asm volatile ("sti; hlt; cli;");
+ GUEST_ASSERT_EQ(ipis_rcvd, 1);
+ return true;
default:
return false;
}
}
+void arch_guest_init(void)
+{
+ x2apic_enable();
+}
+
/*
* This test validates that, during a page walk, if the page a PTE is placed in
* is read-only the accesss and dirty bits will not be written. Note There's a
@@ -181,3 +192,224 @@ static void arch_test_memory_access_pte(struct kvm_vcpu *vcpu, gva_t vaddr)
test_memory_access_pte_ro(vcpu, vaddr);
test_memory_access_sync_spte(vcpu, vaddr);
}
+
+#define IPI_VECTOR 0xfe
+
+static void guest_ipi_handler_hv(struct ex_regs *regs)
+{
+ ipis_rcvd++;
+ wrmsr(HV_X64_MSR_EOI, 1);
+}
+
+/*
+ * This test verifies that the Hyper-V hypercall exit handler takes memory
+ * attributes into account before accessing input data. It coordinates with the
+ * guest through the 'TEST_OP_HYPERV_HYPERCALL_INPUT' operation and instructs
+ * the guest to issue two PV IPIs. The first PV IPI fails because the input
+ * data is held in read-protected memory. Subsequently, the memory protection
+ * is lifted, and the second PV IPI succeeds.
+ */
+static void test_side_channel_hyperv_hypercall_inputs(struct kvm_vcpu *vcpu,
+ gva_t vaddr,
+ size_t size)
+{
+ struct kvm_vm *vm = vcpu->vm;
+ struct hv_send_ipi_ex *ipi_ex = addr_gva2hva(vm, vaddr);
+ gpa_t paddr = addr_gva2gpa(vm, vaddr);
+
+ if (!kvm_has_cap(KVM_CAP_HYPERV_SEND_IPI) ||
+ !kvm_has_cap(KVM_CAP_HCALL_FAULT_EXIT))
+ return;
+
+ vm_enable_cap(vcpu->vm, KVM_CAP_HCALL_FAULT_EXIT, 1);
+
+ ipis_rcvd = 0;
+ vm_install_exception_handler(vm, IPI_VECTOR, guest_ipi_handler_hv);
+ vcpu_set_msr(vcpu, HV_X64_MSR_GUEST_OS_ID, HYPERV_LINUX_OS_ID);
+
+ *ipi_ex = (struct hv_send_ipi_ex){
+ .vector = IPI_VECTOR,
+ .vp_set.format = HV_GENERIC_SET_ALL,
+ };
+
+ vm_set_memory_attributes(vm, paddr, vm->page_size, KVM_MEMORY_ATTRIBUTE_NO_ACCESS);
+ test_page_restricted(vcpu, TEST_OP_HYPERV_HYPERCALL_INPUT, vaddr, paddr,
+ KVM_MEMORY_EXIT_FLAG_READ);
+ vm_set_memory_attributes(vm, paddr, vm->page_size, 0);
+ vcpu_run_and_inc_stage(vcpu);
+}
+
+/*
+ * Verifies that the guest page table walker fails the walk if it encounters a
+ * page table entry address read-protected by a memory attribute.
+ */
+static void test_side_channel_emul_page_walks(struct kvm_vcpu *vcpu,
+ gva_t test_vm_addr,
+ size_t size)
+{
+ const uint64_t pte_addr_mask = GENMASK(51, 12);
+ struct kvm_vm *vm = vcpu->vm;
+ struct kvm_translation tr;
+ int level = PG_LEVEL_1G;
+ gpa_t paddr;
+ uint64_t *pte;
+
+ pte = vm_get_pte_level(vm, test_vm_addr, &level);
+ TEST_ASSERT_EQ(level, PG_LEVEL_1G);
+ paddr = *pte & pte_addr_mask;
+
+ tr = vcpu_translate(vcpu, test_vm_addr);
+ TEST_ASSERT_EQ(tr.valid, true);
+ TEST_ASSERT_EQ(tr.physical_address, addr_gva2gpa(vm, test_vm_addr));
+
+ vm_set_memory_attributes(vm, paddr, vm->page_size, KVM_MEMORY_ATTRIBUTE_NO_ACCESS);
+ tr = vcpu_translate(vcpu, test_vm_addr);
+ TEST_ASSERT_EQ(tr.valid, false);
+
+ vm_set_memory_attributes(vm, paddr, vm->page_size, 0);
+}
+
+static void vm_set_vapic_addr(struct kvm_vcpu *vcpu, uint64_t addr)
+{
+ struct kvm_vapic_addr va;
+
+ va.vapic_addr = addr;
+ vcpu_ioctl(vcpu, KVM_SET_VAPIC_ADDR, &va);
+}
+
+/*
+ * Perform a dummy regs update to issue a KVM_REQ_EVENT. This forces
+ * vapic to be synced before entering the guest.
+ */
+static void vcpu_force_vapic_update(struct kvm_vcpu *vcpu)
+{
+ struct kvm_regs regs;
+
+ vcpu_regs_get(vcpu, ®s);
+ vcpu_regs_set(vcpu, ®s);
+}
+
+/*
+ * Setup the vapic address on a GPA that is write-protected. Force an vapic
+ * update and validate its contents were not changes. Then, lift the write
+ * restriction and validate the page's contents are updated.
+ */
+static void test_side_channel_vapic_addr(struct kvm_vcpu *vcpu)
+{
+ struct kvm_vm *vm = vcpu->vm;
+ gva_t vaddr = vm_alloc_page(vm);
+ gpa_t paddr = addr_gva2gpa(vm, vaddr);
+
+ vm_set_vapic_addr(vcpu, paddr);
+ test_data->op = TEST_OP_READ;
+ test_data->vaddr = vaddr;
+ test_data->confirm_read = 1;
+ test_data->expected_val = ~0ULL >> 32;
+ memset(addr_gva2hva(vm, vaddr), 0xff, sizeof(uint32_t));
+ vm_set_memory_attributes(vm, paddr, vm->page_size, KVM_MEMORY_ATTRIBUTE_NW);
+ vcpu_run_and_inc_stage(vcpu);
+
+ vm_set_memory_attributes(vm, paddr, vm->page_size, 0);
+ vcpu_force_vapic_update(vcpu);
+ test_data->expected_val = 0ULL;
+ vcpu_run_and_inc_stage(vcpu);
+
+ vm_set_vapic_addr(vcpu, 0);
+ test_data->confirm_read = 0;
+}
+
+static void *vcpu_worker(void *data)
+{
+ struct test_data *test_data = data;
+ struct kvm_vcpu *vcpu = test_data->vcpu;
+
+ vcpu_run_and_inc_stage(vcpu);
+
+ return NULL;
+}
+
+/*
+ * Set up the pvclock page and validate that KVM periodically updates the
+ * 'version' field. Subsequently, make the pvclock page non-writable and
+ * verify that the 'version' field is no longer updated.
+ */
+static void test_side_channel_pvclock(struct kvm_vcpu *vcpu)
+{
+ struct kvm_vm *vm = vcpu->vm;
+ gva_t vaddr = vm_alloc_page(vm);
+ gpa_t paddr = addr_gva2gpa(vm, vaddr);
+ struct pvclock_vcpu_time_info *pvclock = addr_gpa2hva(vm, paddr);
+
+ pvclock->version = 0;
+
+ test_data->op = TEST_OP_MONITOR_ADDRESS;
+ test_data->vaddr = vaddr + offsetof(struct pvclock_vcpu_time_info, version);
+ test_data->expected_val = pvclock->version;
+
+ pthread_create(&vcpu_thread, NULL, vcpu_worker, test_data);
+ vcpu_set_msr(vcpu, MSR_KVM_SYSTEM_TIME_NEW, paddr | 0x1);
+ usleep(msecs_to_usecs(1000));
+ TEST_ASSERT_EQ(pthread_tryjoin_np(vcpu_thread, NULL), 0);
+ vcpu_set_msr(vcpu, MSR_KVM_SYSTEM_TIME_NEW, 0);
+
+ test_data->expected_val = pvclock->version;
+ vm_set_memory_attributes(vm, paddr, vm->page_size, KVM_MEMORY_ATTRIBUTE_NW);
+ pthread_create(&vcpu_thread, NULL, vcpu_worker, test_data);
+ vcpu_set_msr(vcpu, MSR_KVM_SYSTEM_TIME_NEW, paddr | 0x1);
+ usleep(msecs_to_usecs(1000));
+ TEST_ASSERT_EQ(pthread_tryjoin_np(vcpu_thread, NULL), EBUSY);
+
+ /* Force the 'monitor_address' guest operation to finish */
+ test_data->op = TEST_OP_NOP;
+ TEST_ASSERT_EQ(pthread_join(vcpu_thread, NULL), 0);
+ vm_set_memory_attributes(vm, paddr, vm->page_size, 0);
+ vcpu_set_msr(vcpu, MSR_KVM_SYSTEM_TIME_NEW, 0);
+}
+
+/*
+ * Write to MSR_KVM_WALL_CLOCK_NEW and verify that the struct's 'version' field
+ * is updated. Subsequently, make the target guest physical address
+ * non-writable, and verify the 'version' field isn't updated anymore.
+ */
+static void test_side_channel_wallclock(struct kvm_vcpu *vcpu)
+{
+ struct kvm_vm *vm = vcpu->vm;
+ gva_t vaddr = vm_alloc_page(vm);
+ gpa_t paddr = addr_gva2gpa(vm, vaddr);
+ struct pvclock_wall_clock *wc = addr_gva2hva(vm, vaddr);
+
+ wc->version = 0x0;
+ vcpu_set_msr(vcpu, MSR_KVM_WALL_CLOCK_NEW, paddr);
+ TEST_ASSERT_EQ(READ_ONCE(wc->version), 2);
+
+ vm_set_memory_attributes(vm, paddr, vm->page_size, KVM_MEMORY_ATTRIBUTE_NW);
+ vcpu_set_msr(vcpu, MSR_KVM_WALL_CLOCK_NEW, paddr);
+ TEST_ASSERT_EQ(READ_ONCE(wc->version), 2);
+
+ vm_set_memory_attributes(vm, paddr, vm->page_size, 0);
+}
+
+/*
+ * Memory attributes are vulnerable to side-channel attacks. This means that
+ * any KVM operation initiated by the guest that requires guest memory access
+ * (which is the case for most pv-interfaces) needs to consider memory
+ * attributes.
+ *
+ * The following tests validate that this requirement is upheld for a variety
+ * of use-cases. These test cases were selected to exercise specific approaches
+ * to accessing guest memory, including:
+ *
+ * - kvm_read/write_guest()
+ * - gfn_to_hva_cache
+ * - gfn_to_pfn_cache
+ * - Guest page walker
+ */
+static void arch_test_side_channels(struct kvm_vcpu *vcpu, gva_t test_vm_addr,
+ size_t size)
+{
+ test_side_channel_hyperv_hypercall_inputs(vcpu, test_vm_addr, size);
+ test_side_channel_emul_page_walks(vcpu, test_vm_addr, size);
+ test_side_channel_vapic_addr(vcpu);
+ test_side_channel_wallclock(vcpu);
+ test_side_channel_pvclock(vcpu);
+}
--
2.52.0
^ permalink raw reply related [flat|nested] 44+ messages in thread* Re: [PATCH v2 28/28] KVM: x86: selftests: Introduce memory attributes side-channel tests
2026-09-18 8:15 ` [PATCH v2 28/28] KVM: x86: selftests: Introduce memory attributes side-channel tests Paolo Bonzini
@ 2026-09-18 8:43 ` sashiko-bot
0 siblings, 0 replies; 44+ messages in thread
From: sashiko-bot @ 2026-09-18 8:43 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: kvm
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] kselftests/kvm: Race condition in pvclock test causes deadlock
--
commit 80c207820949c9e59181f5bf084d4354741225e7
Author: Paolo Bonzini <pbonzini@redhat.com>
KVM: x86: selftests: Introduce memory attributes side-channel tests
This commit introduces memory attributes selftests to catch side-channel
vulnerabilities. It exercises various guest memory access patterns to verify
memory attribute access restrictions are upheld.
> diff --git a/tools/testing/selftests/kvm/memory_attributes.c b/tools/testing/selftests/kvm/memory_attributes.c
> --- a/tools/testing/selftests/kvm/memory_attributes.c
> +++ b/tools/testing/selftests/kvm/memory_attributes.c
[ ... ]
> @@ -86,6 +122,14 @@ static void guest_code(void *data)
> arch_controlled_exec(vaddr);
> GUEST_SYNC(stage++);
> break;
> + case TEST_OP_MONITOR_ADDRESS: {
> + if (arch_controlled_read(vaddr) != expected_val)
> + GUEST_SYNC(stage++);
> + break;
> + }
[Severity: Medium]
Is there a risk of the guest loop getting stuck indefinitely?
In guest_code() under TEST_OP_MONITOR_ADDRESS, the guest spins and does not
trigger a VM-exit unless the value changes. If the host thread is blocked
from updating the expected value, this could cause a deadlock.
[ ... ]
> diff --git a/tools/testing/selftests/kvm/x86/memory_attributes.c b/tools/testing/selftests/kvm/x86/memory_attributes.c
> --- a/tools/testing/selftests/kvm/x86/memory_attributes.c
> +++ b/tools/testing/selftests/kvm/x86/memory_attributes.c
[ ... ]
> +static void test_side_channel_pvclock(struct kvm_vcpu *vcpu)
> +{
> + struct kvm_vm *vm = vcpu->vm;
> + gva_t vaddr = vm_alloc_page(vm);
> + gpa_t paddr = addr_gva2gpa(vm, vaddr);
> + struct pvclock_vcpu_time_info *pvclock = addr_gpa2hva(vm, paddr);
> +
> + pvclock->version = 0;
> +
> + test_data->op = TEST_OP_MONITOR_ADDRESS;
> + test_data->vaddr = vaddr + offsetof(struct pvclock_vcpu_time_info, version);
> + test_data->expected_val = pvclock->version;
> +
> + pthread_create(&vcpu_thread, NULL, vcpu_worker, test_data);
> + vcpu_set_msr(vcpu, MSR_KVM_SYSTEM_TIME_NEW, paddr | 0x1);
[Severity: Medium]
Could this asynchronous sequence lead to a permanent deadlock?
The vcpu_worker thread executes KVM_RUN, which acquires the vcpu->mutex.
Concurrently, the main thread calls vcpu_set_msr(), which triggers
KVM_SET_MSRS and also attempts to acquire vcpu->mutex.
If the worker thread schedules and acquires vcpu->mutex before the main
thread executes vcpu_set_msr(), the main thread will block indefinitely.
Consequently, the MSR is never set, the guest memory is never updated,
and the guest spin loop under TEST_OP_MONITOR_ADDRESS never sees the
updated value. KVM_RUN will thus never return, hanging the test.
> + usleep(msecs_to_usecs(1000));
> + TEST_ASSERT_EQ(pthread_tryjoin_np(vcpu_thread, NULL), 0);
> + vcpu_set_msr(vcpu, MSR_KVM_SYSTEM_TIME_NEW, 0);
> +
> + test_data->expected_val = pvclock->version;
> + vm_set_memory_attributes(vm, paddr, vm->page_size, KVM_MEMORY_ATTRIBUTE_NW);
> + pthread_create(&vcpu_thread, NULL, vcpu_worker, test_data);
> + vcpu_set_msr(vcpu, MSR_KVM_SYSTEM_TIME_NEW, paddr | 0x1);
[Severity: Medium]
This appears to have the exact same race condition leading to deadlock
as the first thread handoff earlier in test_side_channel_pvclock().
If the vcpu_worker acquires vcpu->mutex before the main thread can execute
vcpu_set_msr(), the test will hang waiting for an MSR update that will never
arrive.
> + usleep(msecs_to_usecs(1000));
> + TEST_ASSERT_EQ(pthread_tryjoin_np(vcpu_thread, NULL), EBUSY);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918081543.139871-1-pbonzini@redhat.com?part=28
^ permalink raw reply [flat|nested] 44+ messages in thread