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

[Vincent Donnefort <vdonnefort@google.com>]

On Wed, Jun 10, 2026 at 01:23:04PM +0100, Will Deacon wrote:
> On Wed, Jun 10, 2026 at 01:15:44PM +0100, Vincent Donnefort wrote:
> > 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?
> 
> Maybe? I don't think they'd _have_ to bump the version number.
> 
> > If we really want to check for those arguments to be 0:
> > 
> >  * Shouldn't we extend this check to other FF-A invocations?
> 
> yes, that's what the diff was doing in the reply here:
> 
> https://lore.kernel.org/all/af3fW468-f1KXCrC@google.com/
> 
> but, as I said here:
> 
> https://lore.kernel.org/all/ahmxiFXXTupafbXw@willie-the-truck/
> 
> I don't particularly like the table-driven indirection (the checks
> should just be inlined).

Ha, sorry I'm late to the party. 

Perhaps this series should start with adding ffa_check_unused_args_sbz() to the
existing allowed 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)
> 
> For known arguments, we only need to verify things that can affect EL2.
> I suspect we don't care about a bunch of it.
> 
> Will