Re: [PATCH v7 1/3] KVM: arm64: Block host-initiated FF-A direct responses

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] The ffa_call_supported() denylist omits several critical FF-A interfaces (e.g., FFA_RX_RELEASE, FFA_MSG_SEND2, FFA_RX_ACQUIRE, and the 64-bit FFA_FN64_NOTIFICATION_INFO_GET). This allows these calls to fall through as "supported" and be passed directly to EL3, which leads to both a TOCTOU vulnerability on the hypervisor's RX buffer and the false advertisement of unimplemented interfaces.
--

commit fe4021e3b775f95729beec069334d0e2505a799d
Author: Per Larsen <perlarsen@google.com>

KVM: arm64: Block host-initiated FF-A direct responses
    
This commit blocks the host from initiating FF-A direct responses by
rejecting both the 32-bit and 64-bit calling conventions for
FFA_MSG_SEND_DIRECT_RESP in ffa_call_supported().

> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index a327c2bbb6b64..9e8bb95e8845c 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -686,8 +686,10 @@ static bool ffa_call_supported(u64 func_id)
>  	case FFA_MSG_SEND:
>  	case FFA_MSG_POLL:
>  	case FFA_MSG_WAIT:

[Severity: Critical]
This is a pre-existing issue, but the ffa_call_supported() blocklist omits
several critical FF-A interfaces such as FFA_RX_RELEASE, FFA_MSG_SEND2,
and FFA_RX_ACQUIRE.

Because these missing function IDs return true here, they fall through to
kvm_host_ffa_handler() and are passed directly to EL3 without any locking or
validation:

arch/arm64/kvm/hyp/nvhe/ffa.c:kvm_host_ffa_handler() {
    ...
	if (ffa_call_supported(func_id))
		return false; /* Pass through */
    ...
}

This opens a TOCTOU window on the hypervisor's RX buffer. KVM (EL2) uses
its own hypervisor RX buffer to receive descriptors from EL3. Concurrently,
a malicious host can issue an FFA_RX_RELEASE SMC on another CPU. Since it is
passed directly to EL3 via __kvm_hyp_host_forward_smc() without acquiring
host_buffers.lock, EL3 releases KVM's RX buffer.

Could this allow KVM's RX buffer to be overwritten by new incoming FF-A
messages while KVM CPU 0 is still processing the previous message, letting
the host exploit this to unshare arbitrary hypervisor memory?

Additionally, it seems the 64-bit variant FFA_FN64_NOTIFICATION_INFO_GET
is missing from the blocklist further down in this function, which allows the
host to circumvent the restriction on the 32-bit interface and causes
do_ffa_features() to falsely advertise support for interfaces pKVM does not
implement. Should these missing interfaces also be added to the blocklist?

> -	/* 32-bit variants of 64-bit calls */
> +	/* The host is never the target of a direct request */
>  	case FFA_MSG_SEND_DIRECT_RESP:
> +	case FFA_FN64_MSG_SEND_DIRECT_RESP:
> +	/* 32-bit variants of 64-bit calls */
>  	case FFA_RXTX_MAP:
>  	case FFA_MEM_DONATE:
>  	case FFA_MEM_RETRIEVE_REQ:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260830-host-direct-messages-v7-0-45f6e6db72c2@google.com?part=1