All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Sebastian Ene" <sebastianene@google.com>
Cc: "Marc Zyngier" <maz@kernel.org>,
	kvmarm@lists.linux.dev, "Oliver Upton" <oupton@kernel.org>
Subject: Re: [PATCH v5 3/7] KVM: arm64: Support FFA_NOTIFICATION_BIND in host handler
Date: Tue, 23 Jun 2026 12:07:35 +0000	[thread overview]
Message-ID: <20260623120736.254511F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260623115354.632361-4-sebastianene@google.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] FFA_NOTIFICATION_BIND rejects per-vCPU bindings for VCPU IDs > 0 due to unconditional unused argument check on w5.

Pre-existing issues:
- [High] `ffa_check_unused_args_sbz()` validates the full 64-bit register for SMC32 calls, violating the SMCCC specification.
--

commit 0b8b8b81a4ddcd427b7ffa364b793f45c2dd4f37
Author: Sebastian Ene <sebastianene@google.com>

KVM: arm64: Support FFA_NOTIFICATION_BIND in host handler

Verify the arguments of the FF-A notification bind call and forward the
message to Trustzone.

> 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

[ ... ]

> @@ -930,6 +931,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)) {

[Severity: High]
Does this unconditionally reject per-vCPU bindings for VCPU IDs greater
than 0?

According to the FF-A 1.1 specification, when Flags bit 0 is set to 1,
w5 contains the VCPU ID. This means w5 is not an unused argument when
binding a per-vCPU notification.

Could we skip the sbz check for w5 when the per-vCPU flag is set?

[Severity: High]
This is a pre-existing issue, but I noticed a problem with how
ffa_check_unused_args_sbz() processes SMC32 calls like this one.

When it checks the registers:

static bool ffa_check_unused_args_sbz(struct kvm_cpu_context *ctxt, int first_reg)
{
        ...
        for (reg = first_reg; reg <= end_reg; reg++) {
                if (cpu_reg(ctxt, reg))
                        return true;
        }
        ...
}

It reads the full 64-bit register using cpu_reg(). However, the SMCCC 1.2
specification states that the upper 32 bits of W0-W7 are unpredictable for
SMC32 calls.

Will this cause KVM to spuriously reject valid SMC32 FF-A calls if the
host OS leaves non-zero garbage in the upper 32 bits of the unused
registers?

> +		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);
> +}

[ ... ]

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

  reply	other threads:[~2026-06-23 12:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-23 11:53 [PATCH v5 0/7] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone Sebastian Ene
2026-06-23 11:53 ` [PATCH v5 1/7] KVM: arm64: Enforce strict SBZ checks in the FF-A proxy Sebastian Ene
2026-06-23 12:06   ` sashiko-bot
2026-06-25 13:16   ` Will Deacon
2026-06-26  7:48     ` Sebastian Ene
2026-06-23 11:53 ` [PATCH v5 2/7] KVM: arm64: Forward FFA_NOTIFICATION_BITMAP calls to Trustzone Sebastian Ene
2026-06-23 11:53 ` [PATCH v5 3/7] KVM: arm64: Support FFA_NOTIFICATION_BIND in host handler Sebastian Ene
2026-06-23 12:07   ` sashiko-bot [this message]
2026-06-23 11:53 ` [PATCH v5 4/7] KVM: arm64: Support FFA_NOTIFICATION_UNBIND " Sebastian Ene
2026-06-23 12:05   ` sashiko-bot
2026-06-23 11:53 ` [PATCH v5 5/7] KVM: arm64: Support FFA_NOTIFICATION_SET " Sebastian Ene
2026-06-23 12:01   ` sashiko-bot
2026-06-23 11:53 ` [PATCH v5 6/7] KVM: arm64: Support FFA_NOTIFICATION_GET " Sebastian Ene
2026-06-23 11:53 ` [PATCH v5 7/7] KVM: arm64: Support FFA_NOTIFICATION_INFO_GET " Sebastian Ene
2026-06-23 12:07   ` sashiko-bot

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=20260623120736.254511F000E9@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.