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

[Marc Zyngier <maz@kernel.org>]

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?

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

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.

	M.

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