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@xxxxxxxxx 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