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

[Sebastian Ene <sebastianene@google.com>]

On Wed, May 06, 2026 at 05:29:22PM +0100, Marc Zyngier wrote:

Hello Marc,

> [+ Sudeep]
> 
> On Fri, 01 May 2026 12:44:48 +0100,
> Sebastian Ene <sebastianene@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?
> 

There is no enforcement in place in the hypervisor since we don't proxy
FF-A from guest VMs, there is only one non-secure user of this which is the host.

> >    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?

My understanding is that when the hypervisor doesn't handle the allocation of
the non-secure IDs (through FFA_ID_GET), everything that comes from non-secure
is treated as having the VM ID 0 by the SPMC.

Thanks for having a look,
Sebastian 

> 
> > 
> > 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@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.