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

[Marc Zyngier]

On Thu, 07 May 2026 15:13:06 +0100,
Sebastian Ene <sebastianene at google.com> wrote:
> 
> 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 at 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 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?
> > > > 
> > > 
> > > 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

Does it? How do you verify this?

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

Let's be clear: I don't give a damn about a potential attack vector.
The moment you add Secure to the mix, security is gone (funny, isn't
it?). I care about being strict about the spec, and not letting
through things that will eventually break.

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

Yes, please.

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

I think we need that indeed.

	M.

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