[PATCH v2 0/7] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone

[Will Deacon]

On Wed, Jun 10, 2026 at 10:26:59AM +0100, Vincent Donnefort wrote:
> On Mon, Jun 08, 2026 at 04:55:42PM +0000, Sebastian Ene 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.
> >    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.
> > 
> > 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'.
> 
> As it is only a relayer. Is it really important to check SBZ arguments and
> fields on behalf of Trustzone? It doesn't feel it brings any security. If the
> host passes broken arguments, I don't believe this puts pKVM at risk. Does it? 

I think the problem would be if an update to FF-A allocated some of the
currently SBZ bits to implement some functionality that we would want
to filter at EL2.

Will