arch/arm64/kvm/hyp/nvhe/ffa.c | 190 ++++++++++++++++++++++++++++++++-- 1 file changed, 182 insertions(+), 8 deletions(-)
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'. --- Changes in v2: - enforce the MBZ/SBZ fields - split the calls into separate patches - rebase on 7.1-rc7 Link to v1: https://lore.kernel.org/all/20260501114447.2389222-2-sebastianene@google.com/ Sebastian Ene (7): KVM: arm64: Support FFA_NOTIFICATION_BITMAP_CREATE in host handler KVM: arm64: Support FFA_NOTIFICATION_BITMAP_DESTROY in host handler KVM: arm64: Support FFA_NOTIFICATION_BIND in host handler KVM: arm64: Support FFA_NOTIFICATION_UNBIND in host handler KVM: arm64: Support FFA_NOTIFICATION_SET in host handler KVM: arm64: Support FFA_NOTIFICATION_GET in host handler KVM: arm64: Support FFA_NOTIFICATION_INFO_GET in host handler arch/arm64/kvm/hyp/nvhe/ffa.c | 190 ++++++++++++++++++++++++++++++++-- 1 file changed, 182 insertions(+), 8 deletions(-) -- 2.54.0.1064.gd145956f57-goog
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? > > --- > Changes in v2: > - enforce the MBZ/SBZ fields > - split the calls into separate patches > - rebase on 7.1-rc7 > > Link to v1: > https://lore.kernel.org/all/20260501114447.2389222-2-sebastianene@google.com/ > > Sebastian Ene (7): > KVM: arm64: Support FFA_NOTIFICATION_BITMAP_CREATE in host handler > KVM: arm64: Support FFA_NOTIFICATION_BITMAP_DESTROY in host handler > KVM: arm64: Support FFA_NOTIFICATION_BIND in host handler > KVM: arm64: Support FFA_NOTIFICATION_UNBIND in host handler > KVM: arm64: Support FFA_NOTIFICATION_SET in host handler > KVM: arm64: Support FFA_NOTIFICATION_GET in host handler > KVM: arm64: Support FFA_NOTIFICATION_INFO_GET in host handler > > arch/arm64/kvm/hyp/nvhe/ffa.c | 190 ++++++++++++++++++++++++++++++++-- > 1 file changed, 182 insertions(+), 8 deletions(-) > > -- > 2.54.0.1064.gd145956f57-goog >
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
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
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). > * 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
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
© 2016 - 2026 Red Hat, Inc.