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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250903-loutish-orangutan-of-experience-3dcfda@sudeepholla>
Date: Wed, 3 Sep 2025 15:49:46 +0100
From: Sudeep Holla <sudeep.holla@....com>
To: Andre Przywara <andre.przywara@....com>,
	Paul Benoit <paul@...amperecomputing.com>
Cc: Mark Rutland <mark.rutland@....com>,
	Sudeep Holla <sudeep.holla@....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 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 ?

-- 
Regards,
Sudeep