[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241220082027.15851-1-yan.y.zhao@intel.com>
Date: Fri, 20 Dec 2024 16:20:27 +0800
From: Yan Zhao <yan.y.zhao@...el.com>
To: pbonzini@...hat.com,
seanjc@...gle.com
Cc: peterx@...hat.com,
rick.p.edgecombe@...el.com,
linux-kernel@...r.kernel.org,
kvm@...r.kernel.org,
Yan Zhao <yan.y.zhao@...el.com>
Subject: [PATCH 0/2] KVM: Do not reset dirty GFNs in a memslot not enabling dirty tracking
Hi
This series is for a bug where userspace can request KVM to reset dirty
GFNs belonging to a memslot that does not enable dirty tracking.
Patch 1 provides the fix, which can be applied to Linux 6.13-rc3. Although
the fix is a generic one, its primary motivation is to prevent userspace
from triggering write permission reduction or accessed bit clearing in
mirror SPTEs within TDX VMs. This could otherwise cause mismatches between
mirror SPTEs and the corresponding external SPTEs, and in the worst case,
lead to the removal of the external SPTEs.
Patch 2 introduces a selftest for TDX VMs to demonstrate how userspace
could trigger this bug. If necessary, this test can be ported to the
generic KVM selftest (e.g., dirty_log_test).
Thanks
Yan
Yan Zhao (2):
KVM: Do not reset dirty GFNs in a memslot not enabling dirty tracking
KVM: selftests: TDX: Test dirty ring on a gmemfd slot
tools/testing/selftests/kvm/Makefile | 1 +
.../selftests/kvm/x86_64/tdx_dirty_ring.c | 231 ++++++++++++++++++
virt/kvm/dirty_ring.c | 3 +-
3 files changed, 234 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/kvm/x86_64/tdx_dirty_ring.c
--
2.43.2
Powered by blists - more mailing lists