linux-kernel - Re: [RFC V6 2/2] firmware: arm_scmi: Add quirk to bypass SCP fw bug

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: <Z9kr5ABbqO27_BM-@hovoldconsulting.com>
Date: Tue, 18 Mar 2025 09:16:36 +0100
From: Johan Hovold <johan@...nel.org>
To: Cristian Marussi <cristian.marussi@....com>
Cc: Dan Carpenter <dan.carpenter@...aro.org>,
	Sibi Sankar <quic_sibis@...cinc.com>, sudeep.holla@....com,
	dmitry.baryshkov@...aro.org, maz@...nel.org,
	linux-kernel@...r.kernel.org, arm-scmi@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-arm-msm@...r.kernel.org,
	konradybcio@...nel.org
Subject: Re: [RFC V6 2/2] firmware: arm_scmi: Add quirk to bypass SCP fw bug

Hi Cristian,

On Mon, Mar 03, 2025 at 11:53:52AM +0100, Johan Hovold wrote:
> On Thu, Feb 27, 2025 at 08:34:44AM +0000, Cristian Marussi wrote:
> > On Wed, Feb 26, 2025 at 10:58:44AM +0100, Johan Hovold wrote:
> 
> > > Something like that, yes. :) I didn't try to implement it, but it seems
> > > like it should be possible implement this is a way that keeps the quirk
> > > handling isolated.
> > 
> > I hope next week to have a better look at this, in tne meantime just a
> > few considerations....
> > 
> > Sooner or later we should have introduced some sort of quirk framework
> > in SCMI to deal systematically with potentially out-of-spec FW, but as
> > in the name, it should be some sort of framework where you have a table of
> > quirks, related activation conditions and a few very well isolated points
> > where the quirks are placed and take action if enabled...this does not
> > seem the case here where instead an ad-hoc param is added to the function
> > that needs to be quirked...this does not scale and will make the codebase
> > a mess IMHO...
> 
> Sounds good. At least we have a good understanding now of how this
> particular firmware is broken so it would be great if you could use
> this as a test case for the implementation.
> 
> In summary, we need to force the use of a fast channel for
> PERF_LEVEL_GET on these machines, or possibly fall back to the current
> behaviour of only using the domain attribute to determine whether the
> fast channels should be initialised.
> 
> The latter may allow for a less intrusive implementation even if we'd
> still see:
> 
> 	arm-scmi arm-scmi.0.auto: Failed to get FC for protocol 13 [MSG_ID:6 / RES_ID:0] - ret:-95. Using regular messaging.
> 	arm-scmi arm-scmi.0.auto: Failed to get FC for protocol 13 [MSG_ID:6 / RES_ID:1] - ret:-95. Using regular messaging.
> 	arm-scmi arm-scmi.0.auto: Failed to get FC for protocol 13 [MSG_ID:6 / RES_ID:2] - ret:-95. Using regular messaging.
> 
> when not supported for all messages (e.g. with the current firmware).

> > Anyway, after all of this babbling, I know, talk is cheap :D...so now I will shut
> > up and see if I can prototype something generic to deal with quirks, possibly
> > next week...

Have you made any progress on the quirk framework prototyping?

Do you need any input from Sibi on the protocol versioning for that?

We'd really like to enable cpufreq on this platform and ideally in 6.15.
I think that should be possible given that we now understand in what
ways the firmware is broken and what is needed to handle it even if we
still need to decide on how best to implement this.

Johan