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: <thal4kzpicjancpoop6ct4gjn67k7ypgfi33tzmfstuuj4dzch@smxhbkpqnocg>
Date: Sat, 17 Jan 2026 15:43:27 -0600
From: Bjorn Andersson <andersson@...nel.org>
To: Trilok Soni <trilokkumar.soni@....qualcomm.com>
Cc: Satya Durga Srinivasu Prabhala <satya.prabhala@....qualcomm.com>, 
	Sudeep Holla <sudeep.holla@....com>, 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

On Fri, Jan 16, 2026 at 03:53:57PM -0800, Trilok Soni wrote:
> On 1/16/2026 12:53 PM, Satya Durga Srinivasu Prabhala wrote:
> > Hello Sudeep,
> > 
> > Thanks for the discussion & feedback.
> > 
> > Wanted to check on below possibilities to disable the SMCCC SOC ID at the vendor end, can you help comment?
> > 1. Introduce cmdline option
> >    We are trying to pursue that in Android Kernel - https://android-review.googlesource.com/c/kernel/common/+/3912874
> > 2. Mark SMCCC SMC ID driver as tristate & module as suggested by Dmitry
> > 
> > If any of these other options are agreeable, will send separate patch.
> 
> You broke the replies by top-posting here. 
> 
> > 
> > On 1/16/2026 2:39 AM, Sudeep Holla wrote:
> >> On Thu, Jan 15, 2026 at 10:42:51AM -0800, Satya Durga Srinivasu Prabhala wrote:
[..]
> >>>> The userspace
> >>>> tool seem to have made a wrong assumption and can't expect the kernel to
> >>>> magically fix the issue here.
> >>>>
> >>>> E.g. We didn't disable HMP(a.k.a big little platforms) as the assumptions
> >>>> made by several userspace tools(e.g. lscpu IIRC) was wrong at the time.
> >>> Sorry, at risk of repeating the same thing again, the user space was using
> >>> soc0 interface on Linux Android products for a long time base on vendor
> >>> implementation. While I agree that, user space had some assumptions based
> >>> on vendor implementation, if not disabling the SMCCC SOC ID by default, we
> >>> should at-least have a way to disable it (via cmdline) based on vendor
> >>> requirements.
> >>>
> >> It was the case with lscpu too. We didn't disable HMP just because lscpu
> >> didn't understand or just read cpu0 data. It is exactly the case with
> >> the userspace tool you are mentioning here. Kernel is not providing wrong
> >> data.
> >>
> >>  From the ABI document in the kernel, it has been marked as socX since its
> >> initial addition in 2012. So clearly userspace got it wrong and no one
> >> realised it until now. There is no argument that data provided from the kernel
> >> is wrong in these discussions. So I have nothing else to add unfortunately.
> >>
> 
> I believe that point(s) we have not touched upon are following:
> 
> There will be thousands of Android applications using the native interfaces
> in the playstore in various regions like US and China and so on, which relies
> on getting the SOC_ID to understand the product and enable / disable some features.
> 
> For example, benchmarks like GeekBench or Antutu may also be reading these
> interfaces.
> 
> There are apps. in certain regions which are still not updated from "32-bit"
> to 64-bit on Android yet as an example and there may be no way to reach out
> to those developers to fix but apps. are still used by many users.  
> 
> If we need to move all of these third-party applications to this new interface
> then we have to "break them" before we fix them. Do we want to have such approach?
> 
> We should not have enabled this feature as "default y" in the first place and should
> have kept it as "tristate" or kept it disabled in my opinion.
> 

Kconfig defaults are not a good way to solve such conflicts, there's
nothing saying that ACK wouldn't =y this in their config because it make
sense for a subset of devices.

I share your concerns about the impact to user space applications where
the authors interpreted the API in the same way as I did - there will be
1 soc instance per soc...

Regards,
Bjorn

> ---Trilok Soni
> 
>