Re: [PATCH v3 2/2] KVM: arm64: Support FFA_MEM_RECLAIM2 in host handler

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] KVM: arm64: missing PAGE_SIZE alignment check in do_ffa_mem_reclaim2()
--

commit 98f8a09e41b961093f58b8b2216332b0f1fd7346
Author: Snehal Koukuntla <snehalreddy@google.com>

KVM: arm64: Support FFA_MEM_RECLAIM2 in host handler

This commit adds support for the FF-A v1.3 FFA_MEM_RECLAIM2 interface to the
host FF-A proxy handler in pKVM, validating the constituent descriptors in
the hypervisor TX buffer before forwarding the request to the SPMD and
unsharing the reclaimed ranges from the host stage-2 page tables on success.

Link: https://support.arm.com/documentation/den0140/k

> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index 5ad74ab265b57..2f49ffaa93617 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c

[ ... ]

> @@ -611,6 +624,116 @@ static void __do_ffa_mem_xfer(const u64 func_id,
>  		__do_ffa_mem_xfer((fid), (res), (ctxt));	\
>  	} while (0);
>  
> +static void do_ffa_mem_reclaim2(struct arm_smccc_1_2_regs *res,
> +				struct kvm_cpu_context *ctxt)
> +{

[ ... ]

> +	memcpy(hyp_buffers.tx, host_buffers.tx, (u64)req_desc_cnt * desc_size);
> +
> +	for (in_idx = 0; in_idx < req_desc_cnt; in_idx++) {
> +		range = (void *)hyp_buffers.tx + in_idx * desc_size;
> +		if (check_add_overflow(declared_pages, range->pg_cnt, &declared_pages)) {
> +			ret = FFA_RET_INVALID_PARAMETERS;
> +			goto out_unlock;
> +		}
> +	}
> +
> +	range = (void *)hyp_buffers.tx + offset;
> +	if (declared_pages != total_pages || page_index >= range->pg_cnt) {
> +		ret = FFA_RET_INVALID_PARAMETERS;
> +		goto out_unlock;
> +	}
> +
> +	ffa_mem_reclaim2(res, handle, flags, x3, x4, x5);
> +	if (res->a0 != FFA_SUCCESS)
> +		goto out_unlock;
> +
> +	reclaimed_pages = res->a3;
> +
> +	for (in_idx = offset / desc_size; in_idx < req_desc_cnt; in_idx++) {
> +		struct ffa_mem_region_addr_range temp;
> +		u32 pg_cnt, to_reclaim;
> +
> +		if (reclaimed_count >= reclaimed_pages)
> +			break;
> +
> +		range = (void *)hyp_buffers.tx + in_idx * desc_size;
> +		if (!range->pg_cnt)
> +			continue;
> +
> +		pg_cnt = range->pg_cnt - page_index;
> +		to_reclaim = min(pg_cnt, reclaimed_pages - reclaimed_count);
> +
> +		temp = (struct ffa_mem_region_addr_range) {
> +			.address = range->address + (u64)page_index * FFA_PAGE_SIZE,
> +			.pg_cnt = to_reclaim,
> +		};
> +
> +		WARN_ON(ffa_host_unshare_ranges(&temp, 1));

[Severity: Medium]
On systems where the kernel PAGE_SIZE is larger than FFA_PAGE_SIZE (16 KiB or
64 KiB pages vs. 4 KiB FF-A pages), should do_ffa_mem_reclaim2() in
arch/arm64/kvm/hyp/nvhe/ffa.c verify that each constituent range's address and
byte size, as well as the starting page_index offset, are aligned to PAGE_SIZE
before forwarding the ffa_mem_reclaim2() SMC to EL3?

On the share paths (__do_ffa_mem_xfer() and do_ffa_mem_frag_tx()),
ffa_host_share_ranges() runs prior to the SMC and enforces PAGE_SIZE alignment
in __ffa_host_share_ranges().

In do_ffa_mem_reclaim2(), however, the pre-SMC validation only checks
check_add_overflow(declared_pages, range->pg_cnt, &declared_pages),
declared_pages != total_pages, and page_index >= range->pg_cnt. Once
ffa_mem_reclaim2() succeeds in the SPMC, do_ffa_mem_reclaim2() calls
ffa_host_unshare_ranges(&temp, 1) -> __ffa_host_unshare_ranges():

	for (i = 0; i < nranges; ++i) {
		struct ffa_mem_region_addr_range *range = &ranges[i];
		u64 sz = (u64)range->pg_cnt * FFA_PAGE_SIZE;
		u64 pfn = hyp_phys_to_pfn(range->address);

		if (!PAGE_ALIGNED(sz | range->address))
			break;

If the host passes a descriptor or starting page_index that is not aligned to
PAGE_SIZE, __ffa_host_unshare_ranges() breaks out and returns an error after
EL3 has already reclaimed the pages. Does this trigger the EL2 WARN_ON() and
leave those pages permanently stuck in the PKVM_PAGE_SHARED_OWNED state in the
host stage-2 page tables?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261102141444.1830221-1-snehalreddy@google.com?part=2