All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Ene <sebastianene@google.com>
To: Will Deacon <will@kernel.org>
Cc: catalin.marinas@arm.com, maz@kernel.org, oupton@kernel.org,
	joey.gouly@arm.com, korneld@google.com, kvmarm@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, android-kvm@google.com,
	mrigendra.chaubey@gmail.com, perlarsen@google.com,
	suzuki.poulose@arm.com, vdonnefort@google.com,
	yuzenghui@huawei.com
Subject: Re: [PATCH v5 1/7] KVM: arm64: Enforce strict SBZ checks in the FF-A proxy
Date: Fri, 26 Jun 2026 07:48:44 +0000	[thread overview]
Message-ID: <aj4u3L2RrUDJpmjp@google.com> (raw)
In-Reply-To: <aj0qOFO3pRA-U_mL@willie-the-truck>

On Thu, Jun 25, 2026 at 02:16:40PM +0100, Will Deacon wrote:
> Hi all,
> 
> On Tue, Jun 23, 2026 at 11:53:48AM +0000, Sebastian Ene wrote:
> > 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>
> > Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
> > ---
> >  arch/arm64/kvm/hyp/nvhe/ffa.c | 54 +++++++++++++++++++++++++++++++++++
> >  1 file changed, 54 insertions(+)
> > 
> > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > index 1af722771178..78bb043b33ee 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > @@ -71,6 +71,20 @@ 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;
> > +
> > +	end_reg = ARM_SMCCC_IS_64(func_id) ? 17 : 7;
> > +	for (reg = first_reg; reg <= end_reg; reg++) {
> > +		if (cpu_reg(ctxt, reg))
> > +			return true;
> > +	}
> > +
> > +	return false;
> > +}

Hello Will,

> 
> Seb and I tried taking this for a spin on some Android devices and, sadly,
> it leads to fireworks. The reason is that the FF-A spec quietly changed
> the list of unused parameter registers for 64-bit SMCs from v1.1 to v1.2
> of the spec so that pre-existing calls were affected.
> 
> For example, in v1.1 a 64-bit RXTX_MAP only has x4-x7 as MBZ, whereas in
> v1.2 the same call has x4-x17 as SBZ.
> 
> We can follow the spec by predicating the additional check on the FF-A
> version being >= 1.2, but I'm not hopeful that existing drivers are
> compliant. I also suggest moving this patch to the end of the series in
> case we need to revert it.

I spinned up a new series (v6) which moves the check at the end of the
series and I made it so that it takes the ff-a version into account.

https://lore.kernel.org/all/20260626074545.433234-1-sebastianene@google.com/

> 
> Cheers,
> 
> Will

Thanks
Sebastian

  reply	other threads:[~2026-06-26  7:48 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 [this message]
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
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=aj4u3L2RrUDJpmjp@google.com \
    --to=sebastianene@google.com \
    --cc=android-kvm@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=joey.gouly@arm.com \
    --cc=korneld@google.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=mrigendra.chaubey@gmail.com \
    --cc=oupton@kernel.org \
    --cc=perlarsen@google.com \
    --cc=suzuki.poulose@arm.com \
    --cc=vdonnefort@google.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.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.