linux-kernel - Re: [PATCH] firmware: smccc: Fix Arm SMCCC SOC

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: <20250904-powerful-futuristic-tench-bcebd4@sudeepholla>
Date: Thu, 4 Sep 2025 15:29:42 +0100
From: Sudeep Holla <sudeep.holla@....com>
To: Paul Benoit <paul@...amperecomputing.com>
Cc: Andre Przywara <andre.przywara@....com>,
	Sudeep Holla <sudeep.holla@....com>,
	Mark Rutland <mark.rutland@....com>,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	<linux-arm-kernel@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] firmware: smccc: Fix Arm SMCCC SOC_ID name call

On Wed, Sep 03, 2025 at 05:38:44PM -0400, Paul Benoit wrote:
> On 9/3/2025 10:49 AM, Sudeep Holla wrote:
> > On Wed, Sep 03, 2025 at 03:23:58PM +0100, Sudeep Holla wrote:
> > > On Tue, Sep 02, 2025 at 06:20:53PM +0100, Andre Przywara wrote:
> > > > Commit 5f9c23abc477 ("firmware: smccc: Support optional Arm SMCCC SOC_ID
> > > > name") introduced the SOC_ID name string call, which reports a human
> > > > readable string describing the SoC, as returned by firmware.
> > > > The SMCCC spec v1.6 describes this feature as AArch64 only, since we rely
> > > > on 8 characters to be transmitted per register. Consequently the SMCCC
> > > > call must use the AArch64 calling convention, which requires bit 30 of
> > > > the FID to be set. The spec is a bit confusing here, since it mentions
> > > > that in the parameter description ("2: SoC name (optionally implemented for
> > > > SMC64 calls, ..."), but still prints the FID explicitly as 0x80000002.
> > > > But as this FID is using the SMC32 calling convention (correct for the
> > > > other two calls), it will not match what mainline TF-A is expecting, so
> > > > any call would return NOT_SUPPORTED.
> > > > 
> > > 
> > > Good catch and I must admit I completely missed it inspite of discussing
> > > 32b vs 64b FID around the same time this was introduced.
> > > 
> > > > Add a 64-bit version of the ARCH_SOC_ID FID macro, and use that for the
> > > > SoC name version of the call.
> > > > 
> > > > Fixes: 5f9c23abc477 ("firmware: smccc: Support optional Arm SMCCC SOC_ID name")
> > > > Signed-off-by: Andre Przywara <andre.przywara@....com>
> > > > ---
> > > > Hi,
> > > > 
> > > > as somewhat expected, this now fails on an Ampere machine, which
> > > > reported a string in /sys/devices/soc0/machine before, but is now missing
> > > > this file.
> > > > Any idea what's the best way to handle this? Let the code try the 32-bit
> > > > FID, when the 64-bit one fails? Or handle this as some kind of erratum?
> > > > 
> > > 
> > > Not sure about it yet. Erratum seems good option so that we can avoid
> > > others getting it wrong too as they might just run the kernel and be happy
> > > if the machine sysfs shows up as we decided to do fallback to 32b FID.
> > > 
> > > I will start a discussion to get the spec updated and pushed out and see
> > > how that goes.
> > > 
> > > The change itself looks good and happy to get it merged once we know
> > > what is the best approach(erratum vs fallback).
> > > 
> > 
> > Looking at the SMCCC spec(DEN0028 v1.6 G Edition) ->
> > Section 7.4.6 Implementation responsibilities
> > 
> > If implemented, the firmware:
> > ...
> > • must not implement SoC_ID_type == 2 for SMC32.
> > • can optionally implement SoC_ID_type == 2 for SMC64 (Function ID 0xC000_0002),
> > ...
> > 
> > So Ampere is not spec conformant here and hence I prefer to handle it as
> > erratum. Hopefully we can use SOC_ID version and revision to keep the scope
> > of erratum confined to smallest set of platforms.
> > 
> > Paul,
> > 
> > Thoughts ?
> > 
> 
> Am I correctly understanding that, if the SMC64 SOC_ID Name call fails,
> rather than an unconditional fallback to the SMC32 call, the SMC32
> fallback would only be occurring under the proposed erratum?
>

Correct, if we have unconditional fallback to the SMC32 call, then there
is a chance that this issue gets carried into newer Ampere systems as f/w
gets copied as well as other vendors will also not notice the issue if
they make similar mistake as the kernel silent makes a SMC32 call.

We do need details of  the SoC revision and version for which we need to
apply this workaround/erratum.

> I brought this issue up at a weekly team meeting today, and I'll also be
> communicating with the Ampere Computing firmware team regarding this
> issue.

Thanks!

-- 
Regards,
Sudeep