Yan's series to fix a flaw where a buggy/malicious userspace could coerce
KVM into corrupting TDX SPTEs got me wondering what other bad things userspace
could do by writing into the dirty ring...
The main issue is that KVM doesn't bound the processing of harvested entries
in any way, which allows userspace to keep KVM in a tight loop indefinitely.
E.g.
struct kvm_dirty_gfn *dirty_gfns = vcpu_map_dirty_ring(vcpu);
if (fork()) {
int r;
for (;;) {
r = kvm_vm_reset_dirty_ring(vcpu->vm);
if (r)
printf("RESET %d dirty ring entries\n", r);
}
} else {
int i;
for (i = 0; i < test_dirty_ring_count; i++) {
dirty_gfns[i].slot = TEST_MEM_SLOT_INDEX;
dirty_gfns[i].offset = (i * 64) % host_num_pages;
}
for (;;) {
for (i = 0; i < test_dirty_ring_count; i++)
WRITE_ONCE(dirty_gfns[i].flags, KVM_DIRTY_GFN_F_RESET);
}
}
Patches 1-3 address that class of bugs. Patches 4 and 5 are cleanups.
[*] https://lore.kernel.org/all/20241220082027.15851-1-yan.y.zhao@intel.com
Sean Christopherson (5):
KVM: Bound the number of dirty ring entries in a single reset at
INT_MAX
KVM: Bail from the dirty ring reset flow if a signal is pending
KVM: Conditionally reschedule when resetting the dirty ring
KVM: Check for empty mask of harvested dirty ring entries in caller
KVM: Use mask of harvested dirty ring entries to coalesce dirty ring
resets
include/linux/kvm_dirty_ring.h | 8 ++--
virt/kvm/dirty_ring.c | 88 +++++++++++++++++++++-------------
virt/kvm/kvm_main.c | 9 ++--
3 files changed, 66 insertions(+), 39 deletions(-)
base-commit: 10485c4bc3caad3e93a6a4e99003e8ffffcd826a
--
2.47.1.613.gc27f4b7a9f-goog