Re: [PATCH 28/31] KVM: x86/mmu: Obsolete all roots if memattr contains gPTEs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] kvm: soft lockup in KVM_SET_MEMORY_ATTRIBUTES due to unyielding loop
--

commit c7a249c1f674a4bf236247e82b5eb5accc8a2958
Author: Paolo Bonzini <pbonzini@redhat.com>

KVM: x86/mmu: Obsolete all roots if memattr contains gPTEs

This commit introduces a separate architecture callback for the back half of
kvm_mmu_zap_all_fast() so that obsolete roots can be zapped after the mmu_lock
is dropped. It applies this by checking for guest PTEs when setting memory
attributes and triggering a front-half fast zap if found.

> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 6bbecbae2f8c4..242cbe65859df 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
[ ... ]
> @@ -8326,9 +8327,38 @@ bool kvm_arch_post_set_memory_attributes(struct kvm *kvm,
[ ... ]
> +	/*
> +	 * There are special considerations when applying an memory protection
> +	 * attibute against a page containing guest PTEs, because virtual
> +	 * addresses that requires traversing that page need to fault.
> +	 *
> +	 * When using shadow paging, the PTEs that the CPU actually walks
> +	 * do not have any information about attributes (unlike TDP where
> +	 * the attributes become part of the TDP permission bits).  Since
> +	 * this should be a rare occasion, just invalidate all the mmu roots
> +	 * if shadow paging is in use and attributes do cover a guest PTE.
> +	 */
> +	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;
>  }

[Severity: High]
Does this loop present a denial of service vector?  If userspace calls the
KVM_SET_MEMORY_ATTRIBUTES ioctl with a very large memory range (for example,
1TB), this loop will execute hundreds of millions of iterations doing hash
table lookups.

Because kvm_arch_post_set_memory_attributes() is called with the global
kvm->mmu_lock held for write, and the loop scales linearly with the size of
the update without yielding, can an unprivileged userspace process stall
the host CPU indefinitely, causing RCU stalls and soft lockups?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260918135030.171564-2-pbonzini@redhat.com?part=28