* [PATCH v4 1/7] KVM: arm64: Enforce strict SBZ checks in the FF-A proxy
2026-06-16 15:41 [PATCH v4 0/7] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone Sebastian Ene
@ 2026-06-16 15:41 ` Sebastian Ene
2026-06-16 16:00 ` sashiko-bot
2026-06-16 15:41 ` [PATCH v4 2/7] KVM: arm64: Forward FFA_NOTIFICATION_BITMAP calls to Trustzone Sebastian Ene
` (6 subsequent siblings)
7 siblings, 1 reply; 13+ messages in thread
From: Sebastian Ene @ 2026-06-16 15:41 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
Introduce a helper method ffa_check_unused_args_sbz to enforce strict
arguments checking when the hypervisor acts as a relayer between the
host and Trustzone.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 47 +++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 1af722771178..c64c704f22f8 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -71,6 +71,18 @@ static u32 hyp_ffa_version;
static bool has_version_negotiated;
static hyp_spinlock_t version_lock;
+static bool ffa_check_unused_args_sbz(struct kvm_cpu_context *ctxt, int first_reg)
+{
+ int reg;
+
+ for (reg = first_reg; reg <= 17; reg++) {
+ if (cpu_reg(ctxt, reg))
+ return true;
+ }
+
+ return false;
+}
+
static void ffa_to_smccc_error(struct arm_smccc_1_2_regs *res, u64 ffa_errno)
{
*res = (struct arm_smccc_1_2_regs) {
@@ -239,6 +251,11 @@ static void do_ffa_rxtx_map(struct arm_smccc_1_2_regs *res,
int ret = 0;
void *rx_virt, *tx_virt;
+ if (ffa_check_unused_args_sbz(ctxt, 4)) {
+ ret = FFA_RET_INVALID_PARAMETERS;
+ goto out;
+ }
+
if (npages != (KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE) / FFA_PAGE_SIZE) {
ret = FFA_RET_INVALID_PARAMETERS;
goto out;
@@ -315,6 +332,11 @@ static void do_ffa_rxtx_unmap(struct arm_smccc_1_2_regs *res,
DECLARE_REG(u32, id, ctxt, 1);
int ret = 0;
+ if (ffa_check_unused_args_sbz(ctxt, 2)) {
+ ret = FFA_RET_INVALID_PARAMETERS;
+ goto out;
+ }
+
if (id != HOST_FFA_ID) {
ret = FFA_RET_INVALID_PARAMETERS;
goto out;
@@ -421,6 +443,11 @@ static void do_ffa_mem_frag_tx(struct arm_smccc_1_2_regs *res,
int ret = FFA_RET_INVALID_PARAMETERS;
u32 nr_ranges;
+ if (ffa_check_unused_args_sbz(ctxt, 5)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
if (fraglen > KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE)
goto out;
@@ -482,6 +509,11 @@ static void __do_ffa_mem_xfer(const u64 func_id,
u32 offset, nr_ranges, checked_offset;
int ret = 0;
+ if (ffa_check_unused_args_sbz(ctxt, 5)) {
+ ret = FFA_RET_INVALID_PARAMETERS;
+ goto out;
+ }
+
if (addr_mbz || npages_mbz || fraglen > len ||
fraglen > KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE) {
ret = FFA_RET_INVALID_PARAMETERS;
@@ -581,6 +613,11 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
int ret = 0;
u64 handle;
+ if (ffa_check_unused_args_sbz(ctxt, 4)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
handle = PACK_HANDLE(handle_lo, handle_hi);
hyp_spin_lock(&host_buffers.lock);
@@ -769,6 +806,11 @@ static void do_ffa_version(struct arm_smccc_1_2_regs *res,
{
DECLARE_REG(u32, ffa_req_version, ctxt, 1);
+ if (ffa_check_unused_args_sbz(ctxt, 2)) {
+ res->a0 = FFA_RET_NOT_SUPPORTED;
+ return;
+ }
+
if (FFA_MAJOR_VERSION(ffa_req_version) != 1) {
res->a0 = FFA_RET_NOT_SUPPORTED;
return;
@@ -818,6 +860,11 @@ static void do_ffa_part_get(struct arm_smccc_1_2_regs *res,
DECLARE_REG(u32, flags, ctxt, 5);
u32 count, partition_sz, copy_sz;
+ if (ffa_check_unused_args_sbz(ctxt, 6)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
hyp_spin_lock(&host_buffers.lock);
if (!host_buffers.rx) {
ffa_to_smccc_res(res, FFA_RET_BUSY);
--
2.54.0.1136.gdb2ca164c4-goog
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [PATCH v4 1/7] KVM: arm64: Enforce strict SBZ checks in the FF-A proxy
2026-06-16 15:41 ` [PATCH v4 1/7] KVM: arm64: Enforce strict SBZ checks in the FF-A proxy Sebastian Ene
@ 2026-06-16 16:00 ` sashiko-bot
0 siblings, 0 replies; 13+ messages in thread
From: sashiko-bot @ 2026-06-16 16:00 UTC (permalink / raw)
To: Sebastian Ene; +Cc: Marc Zyngier, kvmarm, Oliver Upton
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
New issues:
- [High] `ffa_check_unused_args_sbz` incorrectly checks preserved registers and the upper 32 bits of parameter registers for SMC32 calls, causing spurious rejections.
- [Low] Missing strict SBZ validation for `FFA_FEATURES`.
Pre-existing issues:
- [Critical] Parser differential between KVM (EL2) and SPMD (EL3) regarding the `ep_mem_offset` field allows the host to bypass pKVM memory isolation.
- [High] Uninitialized EL2 stack memory is leaked to the EL1 host in `do_ffa_version`.
--
commit 5972f4c57539fa5e01e7e9c49f62766ed5e85d37
Author: Sebastian Ene <sebastianene@google.com>
KVM: arm64: Enforce strict SBZ checks in the FF-A proxy
Introduce a helper method ffa_check_unused_args_sbz to enforce strict
arguments checking when the hypervisor acts as a relayer between the
host and Trustzone.
> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index 1af722771178a..c64c704f22f8d 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -71,6 +71,18 @@ static u32 hyp_ffa_version;
> static bool has_version_negotiated;
> static hyp_spinlock_t version_lock;
>
> +static bool ffa_check_unused_args_sbz(struct kvm_cpu_context *ctxt, int first_reg)
> +{
> + int reg;
> +
> + for (reg = first_reg; reg <= 17; reg++) {
> + if (cpu_reg(ctxt, reg))
> + return true;
> + }
> +
> + return false;
> +}
> +
[Severity: High]
Does this loop incorrectly check preserved registers and the upper 32 bits
of parameter registers for SMC32 calls?
According to the SMCCC ABI, SMC32 calls pass parameters in W0-W7, while
X8-X17 are caller-saved preserved registers. The caller does not need to
zero X8-X17, and the upper 32 bits of X0-X7 are architecturally unknown.
Checking these bits using cpu_reg(), which reads the full 64-bit value,
could cause KVM to spuriously reject perfectly valid, spec-compliant SMC32
calls (such as FFA_VERSION and FFA_PARTITION_INFO_GET) if the host or guest
has application data in those registers.
[Severity: Low]
Is the ffa_check_unused_args_sbz() check missing from do_ffa_features()?
According to the FF-A specification (v1.1, section 13.2), parameters W2-W7
for FFA_FEATURES are MBZ. Since this patch introduces strict validation for
other handlers, should do_ffa_features() also enforce this check to prevent
the host from sending garbage in the unused registers?
[ ... ]
> @@ -482,6 +509,11 @@ static void __do_ffa_mem_xfer(const u64 func_id,
> u32 offset, nr_ranges, checked_offset;
> int ret = 0;
>
> + if (ffa_check_unused_args_sbz(ctxt, 5)) {
> + ret = FFA_RET_INVALID_PARAMETERS;
> + goto out;
> + }
> +
[Severity: Critical]
This is a pre-existing issue, but is there a parser differential between
KVM (EL2) and SPMD (EL3) regarding the ep_mem_offset field?
In __do_ffa_mem_xfer(), KVM uses ffa_mem_desc_offset() to locate the
endpoint memory access descriptor:
ep_mem_access = (void *)buf + ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
For FF-A v1.1, this helper statically returns sizeof(struct ffa_mem_region)
and ignores the host-provided buf->ep_mem_offset field. However, SPMD (EL3)
parses the unmodified buffer forwarded by KVM and honors buf->ep_mem_offset.
Could a malicious host set buf->ep_mem_offset to a large value, place a
benign descriptor at the static offset KVM checks, and a malicious
descriptor at the SPMD offset, thereby bypassing KVM's isolation?
[ ... ]
> @@ -769,6 +806,11 @@ static void do_ffa_version(struct arm_smccc_1_2_regs *res,
> {
> DECLARE_REG(u32, ffa_req_version, ctxt, 1);
>
> + if (ffa_check_unused_args_sbz(ctxt, 2)) {
> + res->a0 = FFA_RET_NOT_SUPPORTED;
> + return;
> + }
> +
[Severity: High]
This isn't a bug introduced by this patch, but does returning directly here
leak uninitialized EL2 stack memory to the EL1 host?
In kvm_host_ffa_handler(), struct arm_smccc_1_2_regs res is declared on the
stack without zero-initialization. If this SBZ check fails, the handler
assigns res->a0 and returns immediately without using ffa_to_smccc_res()
(which zeroes the rest of the structure).
Since kvm_host_ffa_handler() then copies all 18 registers into the host's
CPU context:
cpu_reg(ctxt, 17) = res->a17;
does this allow the host to actively trigger a leak of sensitive EL2 stack
memory by supplying non-zero unused arguments?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616154149.2763214-1-sebastianene@google.com?part=1
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v4 2/7] KVM: arm64: Forward FFA_NOTIFICATION_BITMAP calls to Trustzone
2026-06-16 15:41 [PATCH v4 0/7] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone Sebastian Ene
2026-06-16 15:41 ` [PATCH v4 1/7] KVM: arm64: Enforce strict SBZ checks in the FF-A proxy Sebastian Ene
@ 2026-06-16 15:41 ` Sebastian Ene
2026-06-16 15:58 ` sashiko-bot
2026-06-16 15:41 ` [PATCH v4 3/7] KVM: arm64: Support FFA_NOTIFICATION_BIND in host handler Sebastian Ene
` (5 subsequent siblings)
7 siblings, 1 reply; 13+ messages in thread
From: Sebastian Ene @ 2026-06-16 15:41 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
Allow FF-A notification bitmap messages to be forwarded to
Trustzone from the host kernel driver enforce checking for
SBZ fields.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 27 +++++++++++++++++++++++++--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index c64c704f22f8..a72f6d4b62f0 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -713,8 +713,6 @@ static bool ffa_call_supported(u64 func_id)
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:
@@ -909,6 +907,27 @@ static void do_ffa_part_get(struct arm_smccc_1_2_regs *res,
hyp_spin_unlock(&host_buffers.lock);
}
+static void do_ffa_notif_bitmap(struct arm_smccc_1_2_regs *res,
+ struct kvm_cpu_context *ctxt)
+{
+ DECLARE_REG(u32, func_id, ctxt, 0);
+ DECLARE_REG(u32, vmid, ctxt, 1);
+ struct arm_smccc_1_2_regs *args;
+
+ if (ffa_check_unused_args_sbz(ctxt, func_id == FFA_NOTIFICATION_BITMAP_CREATE ? 3 : 2)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ if (vmid != HOST_FFA_ID) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ args = (void *)&ctxt->regs.regs[0];
+ hyp_smccc_1_2_smc(args, res);
+}
+
bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
{
struct arm_smccc_1_2_regs res;
@@ -967,6 +986,10 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
case FFA_PARTITION_INFO_GET:
do_ffa_part_get(&res, host_ctxt);
goto out_handled;
+ case FFA_NOTIFICATION_BITMAP_CREATE:
+ case FFA_NOTIFICATION_BITMAP_DESTROY:
+ do_ffa_notif_bitmap(&res, host_ctxt);
+ goto out_handled;
}
if (ffa_call_supported(func_id))
--
2.54.0.1136.gdb2ca164c4-goog
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [PATCH v4 2/7] KVM: arm64: Forward FFA_NOTIFICATION_BITMAP calls to Trustzone
2026-06-16 15:41 ` [PATCH v4 2/7] KVM: arm64: Forward FFA_NOTIFICATION_BITMAP calls to Trustzone Sebastian Ene
@ 2026-06-16 15:58 ` sashiko-bot
0 siblings, 0 replies; 13+ messages in thread
From: sashiko-bot @ 2026-06-16 15:58 UTC (permalink / raw)
To: Sebastian Ene; +Cc: Oliver Upton, kvmarm, Marc Zyngier
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The FFA_NOTIFICATION_BITMAP_CREATE handler fails to enforce SBZ/MBZ checks on the upper bits of the w2 register.
--
commit d7fbb4e364c5dfed4241ae740e49c01e3b35077f
Author: Sebastian Ene <sebastianene@google.com>
KVM: arm64: Forward FFA_NOTIFICATION_BITMAP calls to Trustzone
This commit allows FF-A notification bitmap messages to be forwarded to
Trustzone from the host kernel driver. It also intends to enforce checking
for SBZ (Should Be Zero) fields.
> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
[ ... ]
> @@ -909,6 +907,27 @@ static void do_ffa_part_get(struct arm_smccc_1_2_regs *res,
> hyp_spin_unlock(&host_buffers.lock);
> }
>
> +static void do_ffa_notif_bitmap(struct arm_smccc_1_2_regs *res,
> + struct kvm_cpu_context *ctxt)
> +{
> + DECLARE_REG(u32, func_id, ctxt, 0);
> + DECLARE_REG(u32, vmid, ctxt, 1);
> + struct arm_smccc_1_2_regs *args;
> +
> + if (ffa_check_unused_args_sbz(ctxt, func_id == FFA_NOTIFICATION_BITMAP_CREATE ? 3 : 2)) {
[Severity: Medium]
The commit message mentions enforcing checks for SBZ fields. For the
FFA_NOTIFICATION_BITMAP_CREATE call, the w2 register contains the
vcpu_count in bits [15:0], while bits [31:16] are defined as MBZ
(Must Be Zero) by the FF-A specification.
While ffa_check_unused_args_sbz() correctly verifies that fully unused
registers (w3-w17) are zero, does this miss validating the upper 16 bits
of the partially-used w2 register before it is passed to TrustZone?
> + ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> + return;
> + }
> +
> + if (vmid != HOST_FFA_ID) {
> + ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> + return;
> + }
> +
> + args = (void *)&ctxt->regs.regs[0];
> + hyp_smccc_1_2_smc(args, res);
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616154149.2763214-1-sebastianene@google.com?part=2
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v4 3/7] KVM: arm64: Support FFA_NOTIFICATION_BIND in host handler
2026-06-16 15:41 [PATCH v4 0/7] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone Sebastian Ene
2026-06-16 15:41 ` [PATCH v4 1/7] KVM: arm64: Enforce strict SBZ checks in the FF-A proxy Sebastian Ene
2026-06-16 15:41 ` [PATCH v4 2/7] KVM: arm64: Forward FFA_NOTIFICATION_BITMAP calls to Trustzone Sebastian Ene
@ 2026-06-16 15:41 ` Sebastian Ene
2026-06-16 15:41 ` [PATCH v4 4/7] KVM: arm64: Support FFA_NOTIFICATION_UNBIND " Sebastian Ene
` (4 subsequent siblings)
7 siblings, 0 replies; 13+ messages in thread
From: Sebastian Ene @ 2026-06-16 15:41 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
Verify the arguments of the FF-A notification bind call and forward the
message to Trustzone.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 32 +++++++++++++++++++++++++++++++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index a72f6d4b62f0..1f38ad008675 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -42,6 +42,8 @@
*/
#define HOST_FFA_ID 0
+#define FFA_NOTIF_RECEIVER_ENDP_MASK GENMASK(15, 0)
+
/*
* A buffer to hold the maximum descriptor size we can see from the host,
* which is required when the SPMD returns a fragmented FFA_MEM_RETRIEVE_RESP
@@ -713,7 +715,6 @@ static bool ffa_call_supported(u64 func_id)
case FFA_MEM_DONATE:
case FFA_MEM_RETRIEVE_REQ:
/* Optional notification interfaces added in FF-A 1.1 */
- case FFA_NOTIFICATION_BIND:
case FFA_NOTIFICATION_UNBIND:
case FFA_NOTIFICATION_SET:
case FFA_NOTIFICATION_GET:
@@ -928,6 +929,32 @@ static void do_ffa_notif_bitmap(struct arm_smccc_1_2_regs *res,
hyp_smccc_1_2_smc(args, res);
}
+static void do_ffa_notif_bind(struct arm_smccc_1_2_regs *res,
+ struct kvm_cpu_context *ctxt)
+{
+ DECLARE_REG(u32, endp_id, ctxt, 1);
+ DECLARE_REG(u32, flags, ctxt, 2);
+ struct arm_smccc_1_2_regs *args;
+
+ if (ffa_check_unused_args_sbz(ctxt, 5)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ if (FIELD_GET(FFA_NOTIF_RECEIVER_ENDP_MASK, endp_id) != HOST_FFA_ID) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ if (flags > 1) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ args = (void *)&ctxt->regs.regs[0];
+ hyp_smccc_1_2_smc(args, res);
+}
+
bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
{
struct arm_smccc_1_2_regs res;
@@ -990,6 +1017,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
case FFA_NOTIFICATION_BITMAP_DESTROY:
do_ffa_notif_bitmap(&res, host_ctxt);
goto out_handled;
+ case FFA_NOTIFICATION_BIND:
+ do_ffa_notif_bind(&res, host_ctxt);
+ goto out_handled;
}
if (ffa_call_supported(func_id))
--
2.54.0.1136.gdb2ca164c4-goog
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v4 4/7] KVM: arm64: Support FFA_NOTIFICATION_UNBIND in host handler
2026-06-16 15:41 [PATCH v4 0/7] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone Sebastian Ene
` (2 preceding siblings ...)
2026-06-16 15:41 ` [PATCH v4 3/7] KVM: arm64: Support FFA_NOTIFICATION_BIND in host handler Sebastian Ene
@ 2026-06-16 15:41 ` Sebastian Ene
2026-06-16 15:41 ` [PATCH v4 5/7] KVM: arm64: Support FFA_NOTIFICATION_SET " Sebastian Ene
` (3 subsequent siblings)
7 siblings, 0 replies; 13+ messages in thread
From: Sebastian Ene @ 2026-06-16 15:41 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
Verify the arguments of the FF-A notification unbind call and forward
the message to Trustzone.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 1f38ad008675..adf8680f3266 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -715,7 +715,6 @@ static bool ffa_call_supported(u64 func_id)
case FFA_MEM_DONATE:
case FFA_MEM_RETRIEVE_REQ:
/* Optional notification interfaces added in FF-A 1.1 */
- case FFA_NOTIFICATION_UNBIND:
case FFA_NOTIFICATION_SET:
case FFA_NOTIFICATION_GET:
case FFA_NOTIFICATION_INFO_GET:
@@ -955,6 +954,27 @@ static void do_ffa_notif_bind(struct arm_smccc_1_2_regs *res,
hyp_smccc_1_2_smc(args, res);
}
+static void do_ffa_notif_unbind(struct arm_smccc_1_2_regs *res,
+ struct kvm_cpu_context *ctxt)
+{
+ DECLARE_REG(u32, endp_id, ctxt, 1);
+ DECLARE_REG(u32, reserved, ctxt, 2);
+ struct arm_smccc_1_2_regs *args;
+
+ if (ffa_check_unused_args_sbz(ctxt, 5) || reserved) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ if (FIELD_GET(FFA_NOTIF_RECEIVER_ENDP_MASK, endp_id) != HOST_FFA_ID) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ args = (void *)&ctxt->regs.regs[0];
+ hyp_smccc_1_2_smc(args, res);
+}
+
bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
{
struct arm_smccc_1_2_regs res;
@@ -1020,6 +1040,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
case FFA_NOTIFICATION_BIND:
do_ffa_notif_bind(&res, host_ctxt);
goto out_handled;
+ case FFA_NOTIFICATION_UNBIND:
+ do_ffa_notif_unbind(&res, host_ctxt);
+ goto out_handled;
}
if (ffa_call_supported(func_id))
--
2.54.0.1136.gdb2ca164c4-goog
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v4 5/7] KVM: arm64: Support FFA_NOTIFICATION_SET in host handler
2026-06-16 15:41 [PATCH v4 0/7] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone Sebastian Ene
` (3 preceding siblings ...)
2026-06-16 15:41 ` [PATCH v4 4/7] KVM: arm64: Support FFA_NOTIFICATION_UNBIND " Sebastian Ene
@ 2026-06-16 15:41 ` Sebastian Ene
2026-06-16 15:54 ` sashiko-bot
2026-06-16 15:41 ` [PATCH v4 6/7] KVM: arm64: Support FFA_NOTIFICATION_GET " Sebastian Ene
` (2 subsequent siblings)
7 siblings, 1 reply; 13+ messages in thread
From: Sebastian Ene @ 2026-06-16 15:41 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
Allow FF-A notification SET messages to be proxied from the pKVM
hypervisor to Trustzone and enforce MBZ/SBZ fields.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 31 ++++++++++++++++++++++++++++++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index adf8680f3266..fdf1e5fb6726 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -43,6 +43,7 @@
#define HOST_FFA_ID 0
#define FFA_NOTIF_RECEIVER_ENDP_MASK GENMASK(15, 0)
+#define FFA_NOTIF_SENDER_ENDP_MASK GENMASK(31, 16)
/*
* A buffer to hold the maximum descriptor size we can see from the host,
@@ -715,7 +716,6 @@ static bool ffa_call_supported(u64 func_id)
case FFA_MEM_DONATE:
case FFA_MEM_RETRIEVE_REQ:
/* Optional notification interfaces added in FF-A 1.1 */
- case FFA_NOTIFICATION_SET:
case FFA_NOTIFICATION_GET:
case FFA_NOTIFICATION_INFO_GET:
/* Optional interfaces added in FF-A 1.2 */
@@ -975,6 +975,32 @@ static void do_ffa_notif_unbind(struct arm_smccc_1_2_regs *res,
hyp_smccc_1_2_smc(args, res);
}
+static void do_ffa_notif_set(struct arm_smccc_1_2_regs *res,
+ struct kvm_cpu_context *ctxt)
+{
+ DECLARE_REG(u32, endp_id, ctxt, 1);
+ DECLARE_REG(u32, flags, ctxt, 2);
+ struct arm_smccc_1_2_regs *args;
+
+ if (FIELD_GET(FFA_NOTIF_SENDER_ENDP_MASK, endp_id) != HOST_FFA_ID) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ if (ffa_check_unused_args_sbz(ctxt, 5)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ if (flags & GENMASK(15, 2)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ args = (void *)&ctxt->regs.regs[0];
+ hyp_smccc_1_2_smc(args, res);
+}
+
bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
{
struct arm_smccc_1_2_regs res;
@@ -1043,6 +1069,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
case FFA_NOTIFICATION_UNBIND:
do_ffa_notif_unbind(&res, host_ctxt);
goto out_handled;
+ case FFA_NOTIFICATION_SET:
+ do_ffa_notif_set(&res, host_ctxt);
+ goto out_handled;
}
if (ffa_call_supported(func_id))
--
2.54.0.1136.gdb2ca164c4-goog
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [PATCH v4 5/7] KVM: arm64: Support FFA_NOTIFICATION_SET in host handler
2026-06-16 15:41 ` [PATCH v4 5/7] KVM: arm64: Support FFA_NOTIFICATION_SET " Sebastian Ene
@ 2026-06-16 15:54 ` sashiko-bot
0 siblings, 0 replies; 13+ messages in thread
From: sashiko-bot @ 2026-06-16 15:54 UTC (permalink / raw)
To: Sebastian Ene; +Cc: kvmarm, Oliver Upton, Marc Zyngier
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The MBZ (Must Be Zero) check for the `flags` parameter (W2) in `do_ffa_notif_set` uses an incorrect mask, leaving bits [31:16] completely unvalidated.
--
commit 18c05e4ad6759f3bb72be1916c4e1abac54bcb30
Author: Sebastian Ene <sebastianene@google.com>
KVM: arm64: Support FFA_NOTIFICATION_SET in host handler
This commit adds support for proxying FF-A notification SET messages from the
pKVM hypervisor to TrustZone. It introduces validation to enforce MBZ and SBZ
fields before forwarding the call.
> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index adf8680f32663..fdf1e5fb67267 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
[ ... ]
> @@ -975,6 +975,32 @@ static void do_ffa_notif_unbind(struct arm_smccc_1_2_regs *res,
> hyp_smccc_1_2_smc(args, res);
> }
>
> +static void do_ffa_notif_set(struct arm_smccc_1_2_regs *res,
> + struct kvm_cpu_context *ctxt)
> +{
> + DECLARE_REG(u32, endp_id, ctxt, 1);
> + DECLARE_REG(u32, flags, ctxt, 2);
> + struct arm_smccc_1_2_regs *args;
> +
> + if (FIELD_GET(FFA_NOTIF_SENDER_ENDP_MASK, endp_id) != HOST_FFA_ID) {
> + ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> + return;
> + }
> +
> + if (ffa_check_unused_args_sbz(ctxt, 5)) {
> + ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> + return;
> + }
> +
> + if (flags & GENMASK(15, 2)) {
[Severity: Medium]
Does this mask properly validate all reserved bits?
The FF-A specification dictates that for the FFA_NOTIFICATION_SET interface,
bits 31 through 2 of the flags parameter passed in W2 are reserved and must
be zero. By using GENMASK(15, 2), the upper 16 bits of the 32-bit flags
variable are completely ignored.
Can this allow a malicious or buggy host to pass non-zero upper bits that
silently bypass validation and get proxied to EL3?
> + ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> + return;
> + }
> +
> + args = (void *)&ctxt->regs.regs[0];
> + hyp_smccc_1_2_smc(args, res);
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616154149.2763214-1-sebastianene@google.com?part=5
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v4 6/7] KVM: arm64: Support FFA_NOTIFICATION_GET in host handler
2026-06-16 15:41 [PATCH v4 0/7] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone Sebastian Ene
` (4 preceding siblings ...)
2026-06-16 15:41 ` [PATCH v4 5/7] KVM: arm64: Support FFA_NOTIFICATION_SET " Sebastian Ene
@ 2026-06-16 15:41 ` Sebastian Ene
2026-06-16 15:41 ` [PATCH v4 7/7] KVM: arm64: Support FFA_NOTIFICATION_INFO_GET " Sebastian Ene
2026-06-23 11:24 ` [PATCH v4 0/7] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone Vincent Donnefort
7 siblings, 0 replies; 13+ messages in thread
From: Sebastian Ene @ 2026-06-16 15:41 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
Allow FF-A notification GET messages to be proxied from the pKVM
hypervisor to Trustzone and enforce MBZ/SBZ fields.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 30 +++++++++++++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index fdf1e5fb6726..de4794338388 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -716,7 +716,6 @@ static bool ffa_call_supported(u64 func_id)
case FFA_MEM_DONATE:
case FFA_MEM_RETRIEVE_REQ:
/* Optional notification interfaces added in FF-A 1.1 */
- 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 */
@@ -1001,6 +1000,32 @@ static void do_ffa_notif_set(struct arm_smccc_1_2_regs *res,
hyp_smccc_1_2_smc(args, res);
}
+static void do_ffa_notif_get(struct arm_smccc_1_2_regs *res,
+ struct kvm_cpu_context *ctxt)
+{
+ DECLARE_REG(u32, endp_id, ctxt, 1);
+ DECLARE_REG(u32, flags, ctxt, 2);
+ struct arm_smccc_1_2_regs *args;
+
+ if (FIELD_GET(FFA_NOTIF_RECEIVER_ENDP_MASK, endp_id) != HOST_FFA_ID) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ if (ffa_check_unused_args_sbz(ctxt, 3)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ if (flags & GENMASK(31, 4)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ args = (void *)&ctxt->regs.regs[0];
+ hyp_smccc_1_2_smc(args, res);
+}
+
bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
{
struct arm_smccc_1_2_regs res;
@@ -1072,6 +1097,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
case FFA_NOTIFICATION_SET:
do_ffa_notif_set(&res, host_ctxt);
goto out_handled;
+ case FFA_NOTIFICATION_GET:
+ do_ffa_notif_get(&res, host_ctxt);
+ goto out_handled;
}
if (ffa_call_supported(func_id))
--
2.54.0.1136.gdb2ca164c4-goog
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v4 7/7] KVM: arm64: Support FFA_NOTIFICATION_INFO_GET in host handler
2026-06-16 15:41 [PATCH v4 0/7] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone Sebastian Ene
` (5 preceding siblings ...)
2026-06-16 15:41 ` [PATCH v4 6/7] KVM: arm64: Support FFA_NOTIFICATION_GET " Sebastian Ene
@ 2026-06-16 15:41 ` Sebastian Ene
2026-06-16 16:03 ` sashiko-bot
2026-06-23 11:24 ` [PATCH v4 0/7] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone Vincent Donnefort
7 siblings, 1 reply; 13+ messages in thread
From: Sebastian Ene @ 2026-06-16 15:41 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
Allow the host to query the FF-A notifiction status and proxy the info
get message to Trustzone. Make sure that the SBZ fields are enforced.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index de4794338388..ffb6d44b5010 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -715,8 +715,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_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 */
@@ -1026,6 +1024,20 @@ static void do_ffa_notif_get(struct arm_smccc_1_2_regs *res,
hyp_smccc_1_2_smc(args, res);
}
+static void do_ffa_notif_info_get(struct arm_smccc_1_2_regs *res,
+ struct kvm_cpu_context *ctxt)
+{
+ struct arm_smccc_1_2_regs *args;
+
+ if (ffa_check_unused_args_sbz(ctxt, 1)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ args = (void *)&ctxt->regs.regs[0];
+ hyp_smccc_1_2_smc(args, res);
+}
+
bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
{
struct arm_smccc_1_2_regs res;
@@ -1100,6 +1112,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
case FFA_NOTIFICATION_GET:
do_ffa_notif_get(&res, host_ctxt);
goto out_handled;
+ case FFA_NOTIFICATION_INFO_GET:
+ do_ffa_notif_info_get(&res, host_ctxt);
+ goto out_handled;
}
if (ffa_call_supported(func_id))
--
2.54.0.1136.gdb2ca164c4-goog
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [PATCH v4 7/7] KVM: arm64: Support FFA_NOTIFICATION_INFO_GET in host handler
2026-06-16 15:41 ` [PATCH v4 7/7] KVM: arm64: Support FFA_NOTIFICATION_INFO_GET " Sebastian Ene
@ 2026-06-16 16:03 ` sashiko-bot
0 siblings, 0 replies; 13+ messages in thread
From: sashiko-bot @ 2026-06-16 16:03 UTC (permalink / raw)
To: Sebastian Ene; +Cc: Oliver Upton, Marc Zyngier, kvmarm
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The 64-bit variant of `FFA_NOTIFICATION_INFO_GET` (`FFA_FN64_NOTIFICATION_INFO_GET`) is not intercepted, allowing the host to bypass the newly added SBZ enforcement.
--
commit 9394d3f8c8ebd222066a0b0a791f85587bdb9eb5
Author: Sebastian Ene <sebastianene@google.com>
KVM: arm64: Support FFA_NOTIFICATION_INFO_GET in host handler
Allow the host to query the FF-A notifiction status and proxy the info
get message to Trustzone. Make sure that the SBZ fields are enforced.
> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index de47943383883..ffb6d44b5010d 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
[ ... ]
> @@ -1100,6 +1112,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
> case FFA_NOTIFICATION_GET:
> do_ffa_notif_get(&res, host_ctxt);
> goto out_handled;
> + case FFA_NOTIFICATION_INFO_GET:
> + do_ffa_notif_info_get(&res, host_ctxt);
> + goto out_handled;
[Severity: Medium]
Does this miss the 64-bit variant (FFA_FN64_NOTIFICATION_INFO_GET)?
If the host natively issues the 64-bit SMC ID, it will fall through this
switch statement. It will then be evaluated by ffa_call_supported(), which
returns true because it is not explicitly blocked. This causes the unvalidated
call to be passed directly through to EL3, bypassing the newly added SBZ
validation entirely.
Should FFA_FN64_NOTIFICATION_INFO_GET be handled here alongside the
32-bit variant to ensure the validation is enforced for both?
> }
>
> if (ffa_call_supported(func_id))
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616154149.2763214-1-sebastianene@google.com?part=7
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v4 0/7] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone
2026-06-16 15:41 [PATCH v4 0/7] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone Sebastian Ene
` (6 preceding siblings ...)
2026-06-16 15:41 ` [PATCH v4 7/7] KVM: arm64: Support FFA_NOTIFICATION_INFO_GET " Sebastian Ene
@ 2026-06-23 11:24 ` Vincent Donnefort
7 siblings, 0 replies; 13+ messages in thread
From: Vincent Donnefort @ 2026-06-23 11:24 UTC (permalink / raw)
To: Sebastian Ene
Cc: catalin.marinas, maz, oupton, will, joey.gouly, korneld, kvmarm,
linux-arm-kernel, linux-kernel, android-kvm, mrigendra.chaubey,
perlarsen, suzuki.poulose, yuzenghui
On Tue, Jun 16, 2026 at 03:41: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'.
For the whole series:
Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
>
> ---
> Changes in v4:
> - previous series(v3) had serious issues with the patch number and it
> appeared like it used a mixed bag from v2 as well. Resend this to
> restore the correct order of the patches.
> - fix strict check in ffa_check_unused_args_sbz and make it "<= 17"
> - check the receiver endpoint Id in
> FFA_NOTIFICATION_BIND/FFA_NOTIFICATION_UNBIND instead of the sender
> - use hyp_smccc_1_2_smc all along
> - check the receiver endpoit Id when doing FFA_NOTIFICATION_GET
>
> Changes in v3:
> - applied Will's suggestion to use the introduced method
> ffa_check_unused_args_sbz for existing calls and added a new
> patch in the beggining of the series to do this.
> - merged the handling of
> FFA_NOTIFICATION_BITMAP_CREATE/FFA_NOTIFICATION_BITMAP_DESTROY into
> one patch as Vincent suggested and create one handler for both.
>
> Changes in v2:
> - enforce the MBZ/SBZ fields
> - split the calls into separate patches
> - rebase on 7.1-rc7
>
> Link to v3:
> https://lore.kernel.org/all/20260616105417.2578670-1-sebastianene@google.com/
> Link to v2:
> https://lore.kernel.org/all/20260608165549.1479409-1-sebastianene@google.com/
> Link to v1:
> https://lore.kernel.org/all/20260501114447.2389222-2-sebastianene@google.com/
>
> Sebastian Ene (7):
> KVM: arm64: Enforce strict SBZ checks in the FF-A proxy
> KVM: arm64: Forward FFA_NOTIFICATION_BITMAP calls to Trustzone
> 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 | 211 ++++++++++++++++++++++++++++++++--
> 1 file changed, 203 insertions(+), 8 deletions(-)
>
> --
> 2.54.0.1136.gdb2ca164c4-goog
>
^ permalink raw reply [flat|nested] 13+ messages in thread