Re: [PATCH v2 16/18] KVM: arm64: Alloc pkvm_hyp_vcpu using pKVM heap allocator

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The pKVM heap allocator (`hyp_alloc`) guarantees only 8-byte alignment, which violates the strict 16-byte alignment requirement of `struct pkvm_hyp_vcpu`.
- [High] Delegating `pkvm_hyp_vcpu` allocation to the global EL2 heap bypasses memory cgroup (memcg) accounting, allowing unprivileged userspace to exceed memory limits.
--

commit 6cb252c4c2be901676d82bdcc257dd6e52864352
Author: Vincent Donnefort <vdonnefort@google.com>

KVM: arm64: Alloc pkvm_hyp_vcpu using pKVM heap allocator

Transition the allocation of the hypervisor vCPU state structure
(pkvm_hyp_vcpu) from the host to the hypervisor using the new pKVM heap
allocator (hyp_alloc()).

> diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
> index 2f616a89f8b35..45ec77e9eca82 100644
> --- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
> +++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c

[ ... ]

> @@ -896,16 +863,15 @@ static int register_hyp_vcpu(struct pkvm_hyp_vm *hyp_vm,
>  	return 0;
>  }
>  
> -int __pkvm_init_vcpu(pkvm_handle_t handle, struct kvm_vcpu *host_vcpu,
> -		     unsigned long vcpu_hva)
> +int __pkvm_init_vcpu(pkvm_handle_t handle, struct kvm_vcpu *host_vcpu)
>  {
>  	struct pkvm_hyp_vcpu *hyp_vcpu;
>  	struct pkvm_hyp_vm *hyp_vm;
>  	int ret;
>  
> -	hyp_vcpu = map_donated_memory(vcpu_hva, sizeof(*hyp_vcpu));
> +	hyp_vcpu = hyp_alloc(sizeof(*hyp_vcpu));

[Severity: High]
Will this allocation guarantee the 16-byte alignment required by
struct pkvm_hyp_vcpu?

The struct embeds a struct kvm_vcpu, which contains a struct
user_fpsimd_state with a __uint128_t vregs[32] array. The C ABI and
AAPCS64 mandate strict 16-byte alignment for 128-bit types.

If hyp_alloc() only guarantees 8-byte alignment (since its MIN_ALLOC_SIZE
is 8), returning an 8-byte aligned pointer could trigger an alignment fault
during compiler-generated SIMD instructions (like LDP Qx, Qy) when
saving or restoring FPSIMD state, potentially leading to a hypervisor panic.

>  	if (!hyp_vcpu)
> -		return -ENOMEM;
> +		return hyp_alloc_errno();
>  
>  	hyp_spin_lock(&vm_table_lock);

[ ... ]

> diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
> index 8a8b5b84825c7..1899b05d9fc22 100644
> --- a/arch/arm64/kvm/pkvm.c
> +++ b/arch/arm64/kvm/pkvm.c

[ ... ]

> @@ -153,28 +153,19 @@ static void __pkvm_destroy_hyp_vm(struct kvm *kvm)
>  
>  	kvm->arch.pkvm.handle = 0;
>  	kvm->arch.pkvm.is_created = false;
> -	free_hyp_memcache(&kvm->arch.pkvm.teardown_mc);
>  	free_hyp_memcache(&kvm->arch.pkvm.stage2_teardown_mc);
>  }
>  
>  static int __pkvm_create_hyp_vcpu(struct kvm_vcpu *vcpu)
>  {
> -	size_t hyp_vcpu_sz = PAGE_ALIGN(PKVM_HYP_VCPU_SIZE);
>  	pkvm_handle_t handle = vcpu->kvm->arch.pkvm.handle;
> -	void *hyp_vcpu;
>  	int ret;
>  
>  	init_hyp_stage2_memcache(&vcpu->arch.pkvm_memcache);
>  
> -	hyp_vcpu = alloc_pages_exact(hyp_vcpu_sz, GFP_KERNEL_ACCOUNT);
> -	if (!hyp_vcpu)
> -		return -ENOMEM;
> -
> -	ret = kvm_call_hyp_nvhe(__pkvm_init_vcpu, handle, vcpu, hyp_vcpu);
> +	ret = pkvm_call_hyp_req(__pkvm_init_vcpu, handle, vcpu);

[Severity: High]
Does this change bypass memory cgroup (memcg) accounting for the vCPU
allocations?

Previously, alloc_pages_exact() used GFP_KERNEL_ACCOUNT, which ensured the
memory was charged to the allocating process. By delegating the allocation
to the EL2 heap via pkvm_call_hyp_req(), a heap depletion will trigger a
top-up request (PKVM_HYP_REQ_HYP_ALLOC).

The host handler for this top-up (pkvm_hyp_topup()) uses
init_hyp_memcache(), which defaults to GFP_KERNEL and omits the
HYP_MEMCACHE_ACCOUNT_KMEMCG flag.

Could this allow an unprivileged userspace process to bypass memcg limits
and exhaust system memory by creating numerous VMs and vCPUs?

>  	if (!ret)
>  		vcpu_set_flag(vcpu, VCPU_PKVM_FINALIZED);
> -	else
> -		free_pages_exact(hyp_vcpu, hyp_vcpu_sz);
>  
>  	return ret;
>  }

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