Re: [RFC PATCH 2/5] KVM: arm64: Split hyp mapping APIs by address type

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but it remains present: Treating EL2 page table allocation failure as fatal by wrapping `pkvm_create_linear_mappings_locked()` in `WARN_ON()`. This converts a recoverable `-ENOMEM` condition into a fatal hypervisor panic.
--

--- Patch [2]: [RFC PATCH 2/5] KVM: arm64: Split hyp mapping APIs by address type ---
commit 7eb3ee309a427de1a370d3d0ea72c38646079ff1
Author: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>

KVM: arm64: Split hyp mapping APIs by address type

This commit replaces create_hyp_mappings() and pkvm_create_mappings()
with explicit symbol and linear-map interfaces to distinguish between
kernel-image symbols and linear-map addresses. It updates all callers
to use the appropriate interface for the address type they provide.

> diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> index 4e329e39a695a..7f815345d6a56 100644
> --- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> +++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> @@ -1109,7 +1109,7 @@ int __pkvm_host_donate_hyp(u64 pfn, u64 nr_pages)
>  		goto unlock;
>  
>  	__hyp_set_page_state_range(phys, size, PKVM_PAGE_OWNED);
> -	WARN_ON(pkvm_create_mappings_locked(virt, virt + size, PAGE_HYP));
> +	WARN_ON(pkvm_create_linear_mappings_locked(virt, virt + size, PAGE_HYP));

[Severity: High]
This is a pre-existing issue, but wrapping pkvm_create_linear_mappings_locked()
in a WARN_ON() in __pkvm_host_donate_hyp() converts a legitimate EL2 page table
allocation failure into a fatal hypervisor panic. At EL2, WARN_ON() expands to
BRK, taking down the host. Because userspace processes can exhaust the EL2
memory pool by triggering operations like host memory donation, could this
panic be used for a host denial-of-service attack?

[ ... ]

> @@ -1175,12 +1175,18 @@ int hyp_pin_shared_mem(void *from, void *to)
>  		goto unlock;
>  
>  	for (cur = start; cur < end; cur += PAGE_SIZE) {
> +		void *addr = (void *)cur;
> +
>  		p = hyp_virt_to_page(cur);
>  		hyp_page_ref_inc(p);
> -		if (p->refcount == 1)
> -			WARN_ON(pkvm_create_mappings_locked((void *)cur,
> -							    (void *)cur + PAGE_SIZE,
> -							    PAGE_HYP));
> +		if (p->refcount == 1) {
> +			int err;
> +
> +			err = pkvm_create_linear_mappings_locked(addr,
> +								 addr + PAGE_SIZE,
> +								 PAGE_HYP);
> +			WARN_ON(err);

[Severity: High]
This isn't a bug introduced by this patch, but similar to the above, wrapping
pkvm_create_linear_mappings_locked() in WARN_ON() in hyp_pin_shared_mem()
treats a legitimate -ENOMEM condition as fatal. If the EL2 buddy allocator
fails when allocating new page table pages, should this path instead return
the error and gracefully fail the hypercall rather than crashing the
hypervisor?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260716140936.4003182-1-aneesh.kumar@kernel.org?part=2