Linux KVM/arm64 development list
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Sebastian Ene" <sebastianene@google.com>
Cc: kvmarm@lists.linux.dev, "Marc Zyngier" <maz@kernel.org>,
	"Oliver Upton" <oupton@kernel.org>
Subject: Re: [PATCH v9 7/7] KVM: arm64: Enforce strict SBZ checks in the FF-A proxy
Date: Mon, 07 Sep 2026 17:33:01 +0000	[thread overview]
Message-ID: <20260907173302.2350C1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260907171930.4037166-8-sebastianene@google.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] ffa_check_unused_args_sbz() incorrectly performs a full 64-bit check on unused arguments for SMC32 calls, violating the SMCCC and spuriously rejecting valid hypercalls.
- [Medium] Lockless concurrent read of hyp_ffa_version inside ffa_check_unused_args_sbz creates a data race when evaluated during concurrent FFA_VERSION calls.
--

commit 97873b3a67790aeb9b9e6b8c8672461b3304a15f
Author: Sebastian Ene <sebastianene@google.com>
KVM: arm64: Enforce strict SBZ checks in the FF-A proxy

This commit introduces 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. It adds checks across various FF-A handlers to ensure
unused arguments in SMC calls are strictly zeroed out.

> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index 2281ac2e42fcb..5ad74ab265b57 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -74,6 +74,21 @@ 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)
> +{
> +	DECLARE_REG(u32, func_id, ctxt, 0);
> +	int reg, end_reg = 7;
> +
> +	if (hyp_ffa_version >= FFA_VERSION_1_2 && ARM_SMCCC_IS_64(func_id))

[Severity: Medium]
Could this lockless read of hyp_ffa_version create a data race?

When the host kernel executes concurrent FFA_VERSION calls, one CPU might 
evaluate the hyp_ffa_version >= FFA_VERSION_1_2 condition here in 
ffa_check_unused_args_sbz(), while another CPU mutates hyp_ffa_version under 
version_lock in do_ffa_version().

Although the 32-bit read compiles to a single atomic load on ARM64 and the 
result is ultimately discarded for FFA_VERSION because 
ARM_SMCCC_IS_64(func_id) evaluates to false, it is still an unprotected 
concurrent access to shared state.

Would reversing the condition to check ARM_SMCCC_IS_64(func_id) first safely 
short-circuit the read for SMC32 calls like FFA_VERSION?

> +		end_reg = 17;
> +	for (reg = first_reg; reg <= end_reg; reg++) {
> +		if (cpu_reg(ctxt, reg))
> +			return true;

[Severity: High]
Does ffa_check_unused_args_sbz() incorrectly perform a full 64-bit check on 
unused arguments for SMC32 calls?

Under the SMCCC 1.2 specification, for SMC32 calls, only the lower 32 bits 
of the registers (W0-W7) are used, and the upper 32 bits are UNPREDICTABLE. 
However, cpu_reg(ctxt, reg) returns the full 64-bit register value.

If a compliant host issues any SMC32 FF-A hypercall (such as FFA_VERSION) 
and leaves non-zero residual data in the upper 32 bits of the unused 
registers, will this strictly reject valid SMC32 hypercalls with 
FFA_RET_INVALID_PARAMETERS? 

Should the register value be masked to 32 bits when ARM_SMCCC_IS_64(func_id) 
is false?

> +	}
> +
> +	return false;
> +}
> +

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260907171930.4037166-1-sebastianene@google.com?part=7

      reply	other threads:[~2026-09-07 17:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-07 17:19 [PATCH v9 0/7] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone Sebastian Ene
2026-09-07 17:19 ` [PATCH v9 1/7] KVM: arm64: Forward FFA_NOTIFICATION_BITMAP calls to Trustzone Sebastian Ene
2026-09-07 17:19 ` [PATCH v9 2/7] KVM: arm64: Support FFA_NOTIFICATION_BIND in host handler Sebastian Ene
2026-09-07 17:19 ` [PATCH v9 3/7] KVM: arm64: Support FFA_NOTIFICATION_UNBIND " Sebastian Ene
2026-09-07 17:32   ` sashiko-bot
2026-09-07 17:19 ` [PATCH v9 4/7] KVM: arm64: Support FFA_NOTIFICATION_SET " Sebastian Ene
2026-09-07 17:19 ` [PATCH v9 5/7] KVM: arm64: Support FFA_NOTIFICATION_GET " Sebastian Ene
2026-09-07 17:19 ` [PATCH v9 6/7] KVM: arm64: Support FFA_NOTIFICATION_INFO_GET " Sebastian Ene
2026-09-07 17:19 ` [PATCH v9 7/7] KVM: arm64: Enforce strict SBZ checks in the FF-A proxy Sebastian Ene
2026-09-07 17:33   ` sashiko-bot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260907173302.2350C1F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=sebastianene@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox