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

[Sebastian Ene <sebastianene@google.com>]

On Thu, May 07, 2026 at 02:36:46PM +0100, Marc Zyngier wrote:
> On Thu, 07 May 2026 11:48:46 +0100,
> Sebastian Ene <sebastianene@google.com> wrote:
> > 
> > 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.
> 
> And again: what makes that VM ID 0? Why can't the host pick VM ID 32
> and use that?
> 

The host discovers its id through the FFA_ID_GET and TZ returns 0 in
this case. However if it wants to use VM ID 32 in any other call it
absolutely can but what would it be the attack here, what is your
concern ?  

> > > >    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.
> 
> This looks terribly fragile. I'd rather you *enforce* these things
> rather than allowing any random stuff from the host and relying on
> the EL3 firmware to get it right (odds are that it won't).
> 

I can verify the vmid is 0 for the notification calls that I enable.

> This also ties into this:
> 
> > > > 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.
> 
> which still remains unanswered.

Missed this sorry. We can reject them in the hyp proxy if the caller
uses non zero values in those registers.

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

Thanks,
Sebastian