Re: [PATCH v7 6/7] KVM: arm64: Support FFA_NOTIFICATION_INFO_GET in host handler

[sashiko-bot@kernel.org]

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

New issues:
- [Critical] Passing through FFA_NOTIFICATION_INFO_GET without RX buffer proxying or locking causes memory corruption and DoS.

Pre-existing issues:
- [High] Missing masking of unsupported optional FF-A 1.1/1.2 interfaces (e.g., FFA_MSG_SEND2) leads to hypervisor information leaks.
--

commit a13e0f442f3327dcf7e9cad61d255528a3a9dd89
Author: Sebastian Ene <sebastianene@google.com>

KVM: arm64: Support FFA_NOTIFICATION_INFO_GET in host handler

This patch allows the host to send FF-A notification queries to Trustzone and
proxy these messages from pKVM.

> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -678,8 +678,6 @@ static bool ffa_call_supported(u64 func_id)
>  	case FFA_RXTX_MAP:
>  	case FFA_MEM_DONATE:
>  	case FFA_MEM_RETRIEVE_REQ:
> -       /* Optional notification interfaces added in FF-A 1.1 */
> -	case FFA_NOTIFICATION_INFO_GET:
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: Critical]
Does removing this from the block list allow the call to pass directly
to EL3 without acquiring host_buffers.lock?

Under the FF-A 1.1 specification, if the endpoints list exceeds register
capacity, EL3 writes it to the caller's (EL2's) RX buffer (hyp_buffers.rx).

If this happens concurrently with do_ffa_mem_reclaim() running on another CPU,
could this un-locked write corrupt the buffer during parsing?

Also, since EL2 does not intercept this to proxy the data or issue an
FFA_RX_RELEASE, will hyp_buffers.rx be left permanently marked 'Full' by EL3,
causing subsequent hypercalls requiring the RX buffer to fail?

[Severity: High]
This is a pre-existing issue, but are we missing masking for other optional
FF-A 1.1/1.2 interfaces like FFA_MSG_SEND2, FFA_RX_ACQUIRE, and
FFA_MEM_PERM_GET here in ffa_call_supported()?

If FFA_MSG_SEND2 passes through to EL3, EL3 will read the message payload
from EL2's TX buffer (hyp_buffers.tx).

Since EL2 does not proxy this call or populate the TX buffer with the host's
data, could EL3 end up sending uninitialized or stale hypervisor memory
(such as previous memory sharing descriptors) to the destination partition?

>  	/* Optional interfaces added in FF-A 1.2 */
>  	case FFA_MSG_SEND_DIRECT_REQ2:		/* Optional per 7.5.1 */
>  	case FFA_MSG_SEND_DIRECT_RESP2:		/* Optional per 7.5.1 */

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260629093558.2425257-1-sebastianene@google.com?part=6