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

[Vincent Donnefort <vdonnefort@google.com>]

On Wed, Jun 10, 2026 at 11:15:14AM +0100, Will Deacon wrote:
> 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.

I suppose that would bump the FF-A version and the proxy would reject it?

If we really want to check for those arguments to be 0:

 * Shouldn't we extend this check to other FF-A invocations?

 * Do we really want to also look into the !SBZ arguments to verify what we can?
   (I'm thinking about the checks on flags)

> 
> Will