Re: [PATCH v3 13/17] KVM: arm64: Alloc pkvm_hyp_vm using pKVM heap allocator

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The transition to the EL2 heap allocator bypasses memcg limits for the hypervisor VM state (pkvm_hyp_vm), allowing an attacker to exhaust kernel memory.
--

--- Patch [13]: [PATCH v3 13/17] KVM: arm64: Alloc pkvm_hyp_vm using pKVM heap allocator ---
commit c6efe6070fc3bbf691ec525e89c4a8f6d1c0cae1
Author: Vincent Donnefort <vdonnefort@google.com>

KVM: arm64: Alloc pkvm_hyp_vm using pKVM heap allocator
    
This commit transitions the allocation of the hypervisor VM state structure
from the host to the hypervisor using the new pKVM heap allocator. The host
now invokes __pkvm_init_vm using pkvm_call_hyp_req(), which handles heap top-up
requests if the hypervisor runs out of memory during initialization.

> diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
> index bfbb1266491d1..a9b85ad37787a 100644
> --- a/arch/arm64/kvm/pkvm.c
> +++ b/arch/arm64/kvm/pkvm.c
[ ... ]
> @@ -209,28 +209,15 @@ static int __pkvm_create_hyp_vm(struct kvm *kvm)
>  	if (!pgd)
>  		return -ENOMEM;
>  
> -	/* Allocate memory to donate to hyp for vm and vcpu pointers. */
> -	hyp_vm_sz = PAGE_ALIGN(size_add(PKVM_HYP_VM_SIZE,
> -					size_mul(sizeof(void *),
> -						 kvm->created_vcpus)));
> -	hyp_vm = alloc_pages_exact(hyp_vm_sz, GFP_KERNEL_ACCOUNT);
> -	if (!hyp_vm) {
> -		ret = -ENOMEM;
> -		goto free_pgd;
> -	}
> -
> -	/* Donate the VM memory to hyp and let hyp initialize it. */
> -	ret = kvm_call_hyp_nvhe(__pkvm_init_vm, kvm, hyp_vm, pgd);
> +	ret = pkvm_call_hyp_req(__pkvm_init_vm, kvm, pgd);

[Severity: High]
Does this transition to the EL2 heap allocator bypass memcg limits for the
hypervisor VM state?

Previously, the host allocated this memory with GFP_KERNEL_ACCOUNT. With this
patch, if EL2's heap allocator runs out of memory, it triggers a top-up
request (PKVM_HYP_REQ_HYP_ALLOC). 

When this top-up request is handled by pkvm_hyp_topup() in the host, it appears
to initialize a temporary memcache without the HYP_MEMCACHE_ACCOUNT_KMEMCG
flag:

arch/arm64/kvm/pkvm.c:pkvm_hyp_topup() {
    ...
    init_hyp_memcache(&mc);
    ret = topup_hyp_memcache(&mc, nr_pages);
    ...
}

This causes hyp_mc_alloc_fn() to fall back to unaccounted GFP_KERNEL
allocations, as it relies on that flag to use GFP_KERNEL_ACCOUNT:

arch/arm64/kvm/mmu.c:hyp_mc_alloc_fn() {
    ...
    gfp = memcache->flags & HYP_MEMCACHE_ACCOUNT_KMEMCG ?
          GFP_KERNEL_ACCOUNT : GFP_KERNEL;
    ...
}

Could this allow an unprivileged userspace process inside a container to
exhaust host kernel memory by repeatedly creating pKVM VMs?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720171513.1415357-1-vdonnefort@google.com?part=13