[PATCH] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone

[Marc Zyngier]

[+ Sudeep]

On Fri, 01 May 2026 12:44:48 +0100,
Sebastian Ene <sebastianene at google.com> wrote:
> 
> Remove the FFA_NOTIFICATION* calls from the blocklist used by the pKVM
> FF-A proxy. This restriction was preventing the use of asynchronous
> signaling mechanisms defined by the Arm FF-A specification to
> communicate with the secure services.
> While these calls are markes as optional, there is no reason why the
> hypervisor proxy would block them because:
> 
> 1. Host is the Sole Non-Secure Endpoint: The Host operates as the
>    only Non-Secure VM ID (VM ID 0) recognized by the Secure World.

Where is this enforced?

>    Because all forwarded notifications are inherently attributed to
>    the Host by the SPMC, there is no risk of VM ID spoofing
>    originating from the Normal World.

I don't understand: either the host is always using VM ID 0, and we
have ways to check and enforce this (how?), or the simple fact that
the request comes from NS is a guarantee that the SPMC will treat the
VM ID as 0.

Which one is it?

> 
> 2. No Memory Pointers or Addresses: The FFA_NOTIFICATION_* ABIs
>    operate strictly via register-based parameters, passing only
>    VM IDs, VCPU IDs, flags, and bitmaps. Because these calls do
>    not contain memory addresses, offsets, or pointers, forwarding
>    them doesn't pose a risk of memory-based confused deputy attack
>    (e.g., tricking the SPMC into overwriting protected memory).
>
> While the pKVM proxy behaves as a relayer, it doesn't currently have its
> own FF-A ID(only the host has the ID 0). The behavior of the setup
> flow is covered by the spec in the: '10.9 Notification support without
> a Hypervisor'.
> 
> Signed-off-by: Sebastian Ene <sebastianene at google.com>
> ---
>  arch/arm64/kvm/hyp/nvhe/ffa.c | 8 --------
>  1 file changed, 8 deletions(-)
> 
> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index 1af722771178..a82d0cd22a17 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -675,14 +675,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_BITMAP_CREATE:
> -	case FFA_NOTIFICATION_BITMAP_DESTROY:
> -	case FFA_NOTIFICATION_BIND:
> -	case FFA_NOTIFICATION_UNBIND:
> -	case FFA_NOTIFICATION_SET:
> -	case FFA_NOTIFICATION_GET:
> -	case FFA_NOTIFICATION_INFO_GET:
>  	/* 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 */

Shouldn't these be sanitised in a way? A bunch of registers are SBZ in
the spec, and I'd expect this to be enforced.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.