linux-kernel - Re: [PATCH 2/7] firmware: arm_scmi: imx: Support discovering buildinfo of MISC protocol

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: <20250708-spirited-pelican-of-renovation-f4218d@sudeepholla>
Date: Tue, 8 Jul 2025 16:38:10 +0100
From: Sudeep Holla <sudeep.holla@....com>
To: Peng Fan <peng.fan@....nxp.com>
Cc: Chuck Cannon <chuck.cannon@....com>,
	Souvik Chakravarty <souvik.chakravarty@....com>,
	Peng Fan <peng.fan@....com>,
	Cristian Marussi <cristian.marussi@....com>,
	Sudeep Holla <sudeep.holla@....com>,
	Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>, <arm-scmi@...r.kernel.org>,
	<imx@...ts.linux.dev>, <linux-arm-kernel@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/7] firmware: arm_scmi: imx: Support discovering
 buildinfo of MISC protocol

On Wed, Jul 09, 2025 at 12:10:06AM +0800, Peng Fan wrote:
> Hi Sudeep,
> 
> Sorry for late reply.
> On Fri, Jul 04, 2025 at 09:59:16AM +0100, Sudeep Holla wrote:
> >On Fri, Jul 04, 2025 at 01:12:04PM +0800, Peng Fan wrote:
> >> Hi Sudeep,
> >> 
> >> On Wed, Jul 02, 2025 at 04:21:40PM +0100, Sudeep Holla wrote:
> >> >On Fri, Jun 27, 2025 at 02:03:45PM +0800, Peng Fan wrote:
> >> >> MISC protocol supports discovering the System Manager(SM) build
> >> >> information including build commit, build time and etc. Add the API
> >> >> for user to retrieve the information from SM.
> >> >> 
> >> >> Signed-off-by: Peng Fan <peng.fan@....com>
> >> >> ---
> >> >>  .../firmware/arm_scmi/vendors/imx/imx-sm-misc.c    | 35 ++++++++++++++++++++++
> >> >>  include/linux/scmi_imx_protocol.h                  | 12 ++++++++
> >> >>  2 files changed, 47 insertions(+)
> >> >> 
> >> >> diff --git a/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
> >> >> index a8915d3b4df518719d56bfff38922625ad9b70f6..1b24d070c6f4856b92f515fcdba5836fd6498ce6 100644
> >> >> --- a/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
> >> >> +++ b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
> >> >> @@ -25,6 +25,7 @@
> >> >>  enum scmi_imx_misc_protocol_cmd {
> >> >>  	SCMI_IMX_MISC_CTRL_SET	= 0x3,
> >> >>  	SCMI_IMX_MISC_CTRL_GET	= 0x4,
> >> >> +	SCMI_IMX_MISC_DISCOVER_BUILDINFO = 0x6,
> >> >
> >> >I clearly missed to raise this point when the documentation for this command
> >> >was added. Anyways I assume, you had explored all the options before adding
> >> >this as generic tools may not be able to pick this up. Instead, I would have
> >> >just stuck with vendor version in the standard protocol with build number
> >> >embedded into it. The date and other info must be implicit from the build.
> >> >
> >> >I try to be more cautious and ask questions in the future as I don't want
> >> >vendor extensions to be dumping ground for really random things like this.
> >> 
> >> +Souvik
> >> 
> >> And Loop our firmware owner to help comment. I just add what the firmware
> >> supports here and allow linux to see the information when the firmware
> >> does not have uart output in some builds.
> >> 
> >> From SCMI spec, it does not restrict what vendor extensions should be like
> >> as I know. So I am not sure what we should do when we define vendor
> >> extensions and what I should do next for this patch.
> >> 
> >
> >Just to be clear, I am not against vendor extensions. I am just saying
> >this interface is not strictly needed. The vendor version could encode
> >this nicely and you could have a map. The only and main concern is having
> >such extensions will not help generic tools as these are very vendor specific.
> >
> >It is good to have firmware version and other related details in a standard
> >format that anyone can understand without the need to dig deeper into vendor
> >specific extensions.
> >
> >Again I am not saying to drop these interfaces, but you will get questioned
> >for its use in the kernel if that doesn't seem like the right approach.
> 
> This is mostly for debug purpose to export the build information to linux,
> such as firmware commit hash.
> 
> Should I still keep current patch, or do you have any suggestions
> with current SM API?  I think there is little chance to update SM to encode
> vendor version to include build date, build num, and commit hash.
> 

I am against using this in the way you are doing in 7/7(i.e. exposing to
the userspace). Just dump the info on the serial port from the init code.
You don't need to expose it scmi_imx_misc_proto_ops as well.

-- 
Regards,
Sudeep