lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <86zfck7pys.wl-maz@kernel.org>
Date: Thu, 31 Jul 2025 08:56:59 +0100
From: Marc Zyngier <maz@...nel.org>
To: Will Deacon <will@...nel.org>
Cc: perlarsen@...gle.com,
	Oliver Upton <oliver.upton@...ux.dev>,
	Joey Gouly <joey.gouly@....com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Zenghui Yu <yuzenghui@...wei.com>,
	Catalin Marinas <catalin.marinas@....com>,
	Sudeep Holla <sudeep.holla@....com>,
	linux-arm-kernel@...ts.infradead.org,
	kvmarm@...ts.linux.dev,
	linux-kernel@...r.kernel.org,
	ahomescu@...gle.com,
	armellel@...gle.com,
	arve@...roid.com,
	ayrton@...gle.com,
	qperret@...gle.com,
	sebastianene@...gle.com,
	qwandor@...gle.com
Subject: Re: [PATCH v7 4/5] KVM: arm64: Bump the supported version of FF-A to 1.2

On Fri, 18 Jul 2025 14:45:17 +0100,
Will Deacon <will@...nel.org> wrote:
> 
> On Tue, Jul 01, 2025 at 10:06:37PM +0000, Per Larsen via B4 Relay wrote:
> > From: Per Larsen <perlarsen@...gle.com>
> > 
> > FF-A version 1.2 introduces the DIRECT_REQ2 ABI. Bump the FF-A version
> > preferred by the hypervisor as a precursor to implementing the 1.2-only
> > FFA_MSG_SEND_DIRECT_REQ2 and FFA_MSG_SEND_RESP2 messaging interfaces.
> > 
> > We must also use SMCCC 1.2 for 64-bit SMCs if hypervisor negotiated FF-A
> > 1.2, so ffa_set_retval is updated and a new function to call 64-bit smcs
> > using SMCCC 1.2 with fallback to SMCCC 1.1 is introduced.
> > 
> > Update ffa_call_supported to mark FF-A 1.2 interfaces as unsupported
> > lest they get forwarded.
> > 
> > Co-developed-by: Ayrton Munoz <ayrton@...gle.com>
> > Signed-off-by: Ayrton Munoz <ayrton@...gle.com>
> > Signed-off-by: Per Larsen <perlarsen@...gle.com>
> > ---
> >  arch/arm64/kvm/hyp/nvhe/ffa.c | 18 ++++++++++++++----
> >  include/linux/arm_ffa.h       |  1 +
> >  2 files changed, 15 insertions(+), 4 deletions(-)
>

[..]

Late catching up on this, as we seem to get a version a day, probably
in the hope that it will keep *something* away,...

> > @@ -734,7 +741,10 @@ static int hyp_ffa_post_init(void)
> >  	if (res.a0 != FFA_SUCCESS)
> >  		return -EOPNOTSUPP;
> >  
> > -	switch (res.a2) {
> > +	if ((res.a2 & GENMASK(15, 2)) != 0 || res.a3 != 0)
> > +		return -EINVAL;
> 
> Why are you checking bits a2[15:2] and a3? The spec says they MBZ,
> so we shouldn't care about enforcing that. In fact, adding the check
> probably means we'll fail if those bits get allocated in future.

I have the exact opposite approach. If we don't check that they are 0
for v1.2 and previous versions, we won't be able to tell what they
mean when they are finally allocated to mean something in version
1.337.

Until we support such version, MBZ should be enforced, because we
otherwise don't understand what the "client" is trying to say. And we
don't understand, we're guaranteed to do the wrong thing.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ