Linux KVM/arm64 development list
 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 v8 6/6] KVM: arm64: Zero out the stack initialized data in the FFA handler
Date: Tue, 30 Jun 2026 11:19:18 +0000	[thread overview]
Message-ID: <20260630111919.1701F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260630102058.3219867-8-sebastianene@google.com>

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

Pre-existing issues:
- [High] Downgrade responses from EL3 during FF-A version negotiation are silently used as a higher version, leading to version desynchronization.
--

commit 301ff1e27b3be974b47bb143428c88b8db810a28
Author: Sebastian Ene <sebastianene@google.com>

KVM: arm64: Zero out the stack initialized data in the FFA handler

Don't leak hypervisor stack data when using the FFA_VERSION call.
When the compiler doesn't support -ftrivial-auto-var-init=zero option
we need to zero out the stack initialized variable before returning data
to the host caller.

Link: https://lore.kernel.org/all/20260616160016.C62C81F000E9@smtp.kernel.org/

> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index bb01d8f830561..7407bc4b547af 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -881,7 +881,7 @@ static void do_ffa_part_get(struct arm_smccc_1_2_regs *res,
>  
>  bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
>  {
> -	struct arm_smccc_1_2_regs res;
> +	struct arm_smccc_1_2_regs res = {0};

[Severity: High]
This is a pre-existing issue, but while looking at how res is handled
during FF-A version negotiation, is it possible for EL2 to silently use
a downgrade response from EL3 as a higher version?

Looking at do_ffa_version() in arch/arm64/kvm/hyp/nvhe/ffa.c:

	hyp_smccc_1_2_smc(&(struct arm_smccc_1_2_regs) {
		.a0 = FFA_VERSION,
		.a1 = ffa_req_version,
	}, res);
	if ((s32)res->a0 == FFA_RET_NOT_SUPPORTED)
		goto unlock;

	hyp_ffa_version = ffa_req_version;

If the host requests a minor version lower than the current hyp_ffa_version,
and EL3 returns a version lower than requested (and not FFA_RET_NOT_SUPPORTED),
EL2 appears to blindly set hyp_ffa_version = ffa_req_version. It ignores the
lower version returned by EL3 in res->a0.

Can this version desynchronization lead to ABI mismatches across the EL2/EL3
security boundary, such as mismatched structure sizes or missing fields?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260630102058.3219867-2-sebastianene@google.com?part=6

      reply	other threads:[~2026-06-30 11:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-30 10:20 [PATCH v8 0/6] arm_ffa, KVM: Fix FF-A emad offset calculations Sebastian Ene
2026-06-30 10:20 ` [PATCH v8 1/6] firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit() Sebastian Ene
2026-06-30 10:20 ` [PATCH v8 2/6] firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation Sebastian Ene
2026-06-30 10:20 ` [PATCH v8 3/6] KVM: arm64: Fix bounds checking in do_ffa_mem_reclaim() Sebastian Ene
2026-06-30 10:53   ` sashiko-bot
2026-06-30 10:20 ` [PATCH v8 4/6] KVM: arm64: Validate the offset to the mem access descriptor Sebastian Ene
2026-06-30 10:20 ` [PATCH v8 5/6] KVM: arm64: Ensure FFA ranges are page aligned Sebastian Ene
2026-06-30 11:08   ` sashiko-bot
2026-06-30 10:20 ` [PATCH v8 6/6] KVM: arm64: Zero out the stack initialized data in the FFA handler Sebastian Ene
2026-06-30 11:19   ` 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=20260630111919.1701F1F000E9@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