linux-kernel - Re: [PATCH] firmware: smccc: default 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <86331062-301b-40b1-9df1-78f7751508b4@oss.qualcomm.com>
Date: Wed, 14 Jan 2026 08:50:23 -0800
From: Satya Durga Srinivasu Prabhala <satya.prabhala@....qualcomm.com>
To: Sudeep Holla <sudeep.holla@....com>
Cc: Mark Rutland <mark.rutland@....com>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>,
        linux-arm-msm@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, trilok.soni@....qualcomm.com
Subject: Re: [PATCH] firmware: smccc: default ARM_SMCCC_SOC_ID to disabled

Hello Sudeep,

On 1/13/2026 4:29 AM, Sudeep Holla wrote:
> On Mon, Jan 12, 2026 at 10:24:06PM -0800, Satya Durga Srinivasu Prabhala wrote:
>> The ARM SMCCC SoC ID driver is currently enabled by default and publishes
>> SMCCC-provided SoC identification into /sys/bus/soc/devices/socX/*.
>>
>> On platforms where a vendor SoC driver already exposes widely-consumed
>> attributes (e.g. Qualcomm socinfo [1]), enabling the SMCCC driver changes
>> the format of /sys/devices/soc0/soc_id (e.g. "jep106:XXYY:ZZZZ" instead
>> of a vendor logical ID like "519") and breaks existing userspace consumers.
>>
> Instead of relying on a vendor-specific SoC driver, we should consider
> disabling it and using the OS-agnostic SoC information interface provided by
> the firmware.
Would like to add some history here. Vendor interface existed [1] even 
before
SMCCC SMC ID was introduced [2]. And there are several user space 
entities which
uses the soc0 interface already.
> The presence of this interface strongly suggests that the
> firmware is designed to support multiple operating systems or software stacks
> that already depend on it.
That is correct. We started seeing the issue with user space when our 
firmware
started implementing support for SMCCC SOC ID recently for non-Linux 
based product.
As the firmware remain same across OSes, user space is broken on Linux.
> Aligning the Linux kernel with this
> firmware-defined, OS-agnostic mechanism would reduce vendor-specific
> dependencies and improve portability. Any gaps can be addressed by enhancing
> userspace to correctly parse and consume this information.
Agree. Updating entire use space would need time and we are looking to see
if vendor specific interface can be given priority over the standard 
interface.
>   Given these
> advantages, why would this approach not be the better long-term solution?
As mentioned above, existing user space will be broken and fixing 
existing user
space is going to take time. As the feature itself is "optional" from SMCCC
specification, if we can't disable by default, we should at-least have a way
to disable the feature by other means.


[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/soc/qcom/socinfo.c?id=efb448d0a3fca01bb987dd70963da6185b81751e
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/firmware/smccc/soc_id.c?id=821b67fa46390baea0ac5139a60eaa48805261b2